Why I’m not enthusiastic about Java 10

Roman Elizarov
5 min readMar 22, 2018

Java 10 has been recently released. One of its new features is JEP 286: Local-Variable Type Inference. Java programmers are enthusiastic about it and one particular tweet caught my attention:

I’ve been a happy Java programmer for 15+ years, Java Champion, Certified Java Developer, Staunch Defender of Java, etc, etc, and just a few years ago I would have been as enthusiastic about it, too. If somebody had told me that Scala, for example, had had this particular type inference feature for more than 10 years, I would have just laughed and tried to convert this person back to the holiness of Java, since I have had first-hand experience of Scala’s limitations for real-life enterprise projects. Surely, I would have thought, it is for everybody’s benefit to adopt good parts of Scala (or rather C#, for that matter) into Java. It could not cause any harm, could it?

So what had changed for me? It is easy to guess — I’ve discovered Kotlin. But why would replacing Scala with Kotlin in the previous paragraph makes it somehow different? Why shouldn’t Java developers dismiss Kotlin in the same way they’ve been dismissing Scala and other alternative JVM languages all this time? I’ve sincerely been this dismissive person and I can give you a first-hand answer.

Let’s take Scala for example. Learning Scala for Java developer goes like this: “Wow, wow, this is so cool, how could I have lived without it!”, but use Scala in production for over a few months beyond some limited number of isolated domains where it really shines, and you quickly start discovering its limitations in tooling support, compile times, write-only code, backwards compatibility, interoperability. The latter, interoperability, seems minor in this list and is rarely mentioned, but it is, in fact, a show-stopper, so I’ll elaborate. On paper Scala works on JVM platform and should therefore seamlessly work with all JVM libraries and frameworks. In practice, try mixing Java and Scala code in the same project and you quickly discover that it just ain’t so. Compiling to the same byte-code is not enough. Idiomatic Scala code is too different from idiomatic Java code, causing impedance mismatches all over the place. So, Scala was easy to dismiss for me. Similar with other alternatives.

Learning Kotlin for Java developer goes like this: “Wow, wow, this is so cool, how could I have lived without it!”, but use Kotlin in production for over a few months and you don’t run into any big problems. Yes, there are some deficiencies and bugs here and there, but there is nothing serious to spoil your work. The more you use Kotlin, the more you enjoy it. You start appreciating things Kotlin does differently than Java and rationale behind them and things Kotlin does in the same way as Java, so that it is easier to interoperate with Java. And it is not an accident. Kotlin was designed with Java developers in mind, it was designed to be easy to learn for Java developers, it was designed to gradually replace Java in big enterprise projects file-by-file.

Stephen Colebourne had this great (albeit controversial) insight back in 2010 on The Next Big JVM Language:

Maybe we should reconsider Java? What if we created a backwards incompatible version of Java (the language)? Where we fixed the things we know are broken? (exposed primitives, arrays, checked exceptions, …Where the changes were not too massive to create the need for formal training courses? Where a tool converts old code to new code (and vice versa) with 100% accuracy? (providing the essential backwards compatibility) Where features like closures and properties could be added with the current compromises? Where you only compile modules, and never single class files?

That post had aged quite well. Go and (re)read it. You’ll find that Kotlin is basically a realization of Stephen’s vision for backwards-incompatible version of Java he was asking Oracle to do instead of JDK 8/9. Kotlin fixes Java’s bad parts and keeps its good parts. Indeed, Kotlin was designed to be Java 2.0. With Kotlin you can truly enjoy the greatness of JVM ecosystem that makes it the platform of choice for so many projects today. As a side note, I do consider JVM, the platform, to be much more valuable invention than Java, the language.

How all of this changes my perception on the progress of Java? I’ve been programming in Java way, way longer than I’ve been programming in Kotlin and, surely, additional competition in the space of programming languages would never harm. I would not have reacted like this if the tweet was about, for example, some new feature in Swift, even if it fully mimicked an existing Kotlin feature. But here my natural reaction was:

I’m just not enthusiastic about new Java features anymore and it had become hard for me to feel for this enthusiasm of Java developers. I view new Java language features as a distraction from the improvements of JVM platform that the whole JVM ecosystem would benefit from. There is no reason in my mind to spend time and effort adding new features to Java (the language). There are simply too many known flaws in Java design that are hard or impossible to fix in a backwards compatible way anyway. Frankly, improving Java language looks to me now like putting a lipstick on a pig.

I, as a developer still dealing with Java daily, don’t need any more Java language features. We already have Kotlin, designed to be a better Java. Java should be maintained and cared about, since we have so much great and useful code written in Java. I believe that the more stable Java stays, the better it is for our future and for the future of JVM ecosystem.

There is an anecdotal evidence that this feeling is shared by virtually every Java developer who went beyond reading about Kotlin into writing some real production code with Kotlin. If you are still writing new code in Java, you should seriously consider start writing it in Kotlin instead. You will not regret. The more you do it, the more you love it.

Postscriptum

In retrospect, my answer to Lukas’s tweet was not appropriate. I failed to recognize his true enthusiasm and considered it as a sarcastic exchange of opinions that would not hurt anyone’s feelings. It did, and I’m sorry for that.

UPDATE: I’ve edited some of the generalizations (from me, personally, to all the programmers) that I had in the original post. They were offensive and distracting to the overall theme of this post that was supposed to share my personal feelings.

--

--

Roman Elizarov

Project Lead for the Kotlin Programming Language @JetBrains