Tag Archives: scala

The Rise and Fall of Scala

There seems to be a consensus in the Java community that the Scala programming language is already on the decline. I consider this a pity because I always enjoyed programming in Scala. Actually, I even started this blog to support alternative JVM languages like Scala. But the market has decided differently. Moshe Kranc has written an excellent analysis about the rise and fall of Scala. I found Moshe’s article interesting enough to summarize it and to add a couple of thoughts of mine.

Before I start

However, I’ve also read some of the 169 comments to Moshe’s article, so I’d like to add a few words. First of all, I’m really fond of the Scala language. I’m not trying to write an anti-Scala article. Quite the contrary. I’m following the fate of Groovy and Scala for at least ten years now, and I’m still puzzled why the industry doesn’t adopt one of these languages. In many aspects, both languages are clearly superior to Java.
Continue reading

Newsflash: Java to Scala Converter

JavaToScala.com may help you to learn Scala. It takes an arbitrary Java class and converts it to Scala.

Naturally, this approach emphasizes the similarities between the two languages. The few examples I tried were converted into solid Scala classes, but nothing out of the ordinary. The converter won’t introduce a case class or a trait if it seems fit. However, emphasizing the similarities is not a bad thing: many Java programmers are scared away from Scala after seeing advanced code.

The core of the converter is another project available on GitHub: Scalagen is a Maven plugin converting Java source code to Scala. The project home page states that the converter isn’t perfect, but may introduce errors for certain Java constructs, so I take it the same applies for JavaToScala.com. But still, it’s an interesting way to get familiar with Scala.

Scala.js

When I heard about Scala.js a couple of years ago, I thought to myself: “Well, that’s an interesting project, but sure it’s bound to fail”. Only it didn’t. The other day I’ve stumbled over an impressive technology demo. You can write a ray tracer in object-oriented and functional Scala, compile it to Javascript an run it in the browser. Ray tracers are power-hungry, so the good performance shows that Scala.js generates surprisingly good code. I didn’t run benchmarks, but judging from what I’ve seen I believe Scala.js is “good enough” on a modern browser. Native Javascript may be faster, but in many cases you won’t notice the difference.
Continue reading

Teaching Scala as the First Programming Language?

A couple of years ago I proposed to teach our company’s students Scala instead of Java. At the time my suggestion was rejected. That’s a pity: I’m pretty much convinced it might have helped our apprentices a lot. So I’m happy to learn other people are not so shy. Recently I’ve read two articles on the topic, both relating positive experiences.

Continue reading

Blazing Fast Pure Java Mixins Using Advanced Javassist

Last week I showed you how to utilize the Javassist library to mix up several Java classes into one. That’s more or less the concept of “mixins” most modern programming languages offer.

The most important disadvantage of my approach is it mixes the classes at run time. Your compiler can’t help you. Neither can your IDE. So my idea may deliver the features of a mixin, but it doesn’t look nor feel like a mixin. You need an interface or a type cast to access every method of the mixin – something you don’t need in, say, Scala.

There’s nothing I can do about that. Java’s just the way it is. If you aren’t happy with it, use a more modern language :).

What we can fix is the second disadvantage: performance. That’s what we’ll do today.
Continue reading

Using Javassist To Implement Mixins or Traits in Java

Many components of the AngularFaces library share common properties and methods. Some of these methods are simple, some of them are complex. I’d like to move them to another class instead of implementing them multiple times. Unfortunately the component classes don’t derive from a common base class. That’s nothing I can fix. That’s just the way PrimeFaces and Mojarra are designed. So I can’t factor out the common traits using inheritance.

The second common approach, the delegation pattern, certainly works. However, it amounts to writing a lot of boiler plate code. At first glance, this isn’t much of a problem since most modern IDEs offer a refactoring tool to implement the boiler plate code. Eclipse is going to help you. But as Venkat Subramaniam points out in his Java One 2013 talk (roughly at 31:30), this approach has severe disadvantages. Adding a method to the base class forces you to add it to every class using the base class as a delegate. The same applies to removing a method or changing a methods signature.

So what we really want to have is something like Scala’s trait or Groovy’s @delegate annotation. This is often referred to as “mixin”.1 Basically, it’s a kind of multiple inheritance, but typically mixins or traits are defined in a slightly less anarchic way. For instance, the famous diamond inheritance problem of C++ simply can’t occur.

However, porting AngularFaces to another JVM language might reduce the library’s attractiveness to other developers, not to mention it’s versatility. Virtually every JVM language features nice integration with Java, but few JVM languages play nicely with other JVM languages other than Java.

Some time ago I’ve seen a surprising approach to implement mixins using AspectJ. But again, AspectJ might repel some Java developers and adds to the tool stack.

Another possibility is to wait for Java 8. Defender methods deliver most of the functionality I’m missing. But I don’t know how long it takes until OpenShift – where I host the AngularFaces showcase – is going to support Java 8, so this isn’t an attractive option, either.

So it’s tempting to abandon all hope. But wait – what about Javassist?
Continue reading

  1. There are subtle differences between the terms “mixin” and “trait”. However, the differences aren’t that big, so I’m using both terms as synonims in this article.