On the road to Bandol

In a very varied day, I continued with a little geek recreation, in a session from OpenGamma‘s Stephen Colebourne, wondering what language may take on Java in the coming years as future for the JVM. This presentation was actually very good, and made even better by the fact that it was not delivered by an Oracle employee. Since I mostly listened without taking notes, so I have little to say today; I’ll try to catch up when the slides will be available.

The main premises for the talk are that (1) Java’s Virtual Machine is very good, that a lot of effort has been spent making it the most efficient execution platform around, and (2) the Java language is getting old after 15 years, and another language is going to take over.

For now, I will simply list the seven sins of Java, i.e. the answers provided by the speaker to the question “Whad did Java get wrong?”. Before to do so, I will remind that he actually took great precautions about reminding us that this list was his list, although he has tried to use as much fact as possible. Also, this list is established after 15 years of experience, and the fact that something is mentioned there simply means that it didn’t turn out to be a good idea, not that it wasn’t when Java was first designed. So, here they are:

1. Checked exceptions. Sounds good at first, until we start writing empty catch clauses. The debate remains open, but most big frameworks (Java EE, Spring) didn’t keep them, so it doesn’t sound good.
2. Primitive types. They used to be good, but now, they can be removed, because this breaks the “everything is an object” principle for a simple optimization. Today, we can leave that job to compilers.
3. Arrays. Like primitives, it breaks the “everything is an object” principle, and compilers can discover them. I feel less comfortable with that one, mostly because I believe that developers can screw up static analyzers and compilers on that one.
4. Everything is a monitor. If you synchronize on a String, it doesn’t work, because it may be interned. And also, this ability to synchronize on anything breaks many JVM optimizations.
5. Statics. They are not objects, and their use is not obvious. An explicit mechanism for singletons would be better.
6. Method overloading. Here, we are only talking of overloading with the same number of arguments. This thing was not good, but autoboxing made it almost impossible to figure out which method is running in some cases, and this is not good.
7. Generic wildcards and variance. Wildcards are generics gone wild, and they can be very difficult to understand, and therefore, use correctly.

Then, Stephen Colebourne went into a description of desirable features for Java’s successor, and looked at several candidates for this successor. This part was very interesting, so I didn’t take notes. As an example, I will simply give one desirable feature:

Java is a blue-collar language, used by over 10 million developers. This means that the target market for Java is not made of alpha geeks who comment on features, but of real engineers who build complex applications with Java. I think that this is really difficult to grasp, because the guys who design the language usually are in the alpha geek category. This means that they will need to have alot of empathy for blue-collar developers, and we all know that this may not be very easy.

Finally, for those who want to read it before looking at the slides, here is the conclusion, after the break.

I thought for a long time that Stephan wanted to promote his company’s particular language, but it wasn’t the conclusion (OpenGamme does not even design languages). His goal was actually to break one of the major assumptions of Java evolution: backward compatibility. His goal is to convince Oracle to break backward compatibility with Java 8, with a fresh start. Of course, tools translating from Java 7 to Java 8 would be available, and the guy also wants a bit more control for the community. Maybe that he should have been wearing Gosling’s T-shirt.