JVM Weekly #5 - Classfile API, advantages of Kotlin, migration to Java 11 on LinkedIn

This week represents for me the quintessence of what I define as "quiet". That's why we're going to talk about the important "obvious," often forgotten in the pursuit of news. As a bonus: new JEP.

1. Classfile API - Native API to generate classes will go to Java

Even in quieter weeks like this, Brian Goetz can always be counted on. He has, quite suddenly, published a JEP on a topic that has very little to do with the most "vocal" issues that have been discussed in the JVM lately. The Draft Classfile API in itself won't sway the lives of "industry" programmers, but library developers will get another small, useful addition to the standard library, allowing them to minimize dependencies.

To quote JEP himself here - a great many Java tools rely on class generation - that's the whole legendary magic of many tools.

Until now it was necessary to use external libraries for this. The JDK developers, however, decided to make the whole process easier. They want to achieve that by proposing to create a powerful API for reading, writing, and transforming class files. The advantage of the tool, not so obvious at first sight, is a guarantee of compatibility with the current version of Java and all new changes coming with each JDK. Brian Goetz insists in the proposal that the developers' aim is not to replace existing libraries. He simply plans to come out ahead for those who don't want to wonder which version of ByteBuddy will be suitable.

It's not, of course, that Java has no way to manipulate classes. As the new proposal nicely points out, in the "guts" of the JVM there is e.g. an ASM library (jdk.internal.org.objectweb.asm.ClassReader), which is used, among other things, by Lambda-related classes. This raises an interesting "egg and chicken" problem - as the Java code has to be stable in order to finalise the JDK versions, the ASM (which is a library) in the Java internals is always a step behind the main Java release. There are quite a few "minor" libraries like Xalan or cglib in the JDK, and the new API is supposed to clean up the project internals by consolidating these

Why now? The developers argue that the evolution of the JVM has greatly accelerated and more and more changes are taking place at the level of generated code. With the new API, large initiatives like Valhalla are expected to be less disruptive to the entire ecosystem.

At this point I started to wonder - how much stuff will actually break with the advent of Value Type? Something tells me that this information is what motivated Brian Goetz to write the hero of today's review.

2. What really hurts Kotlin programmers when returning to Java?

The second of today's texts is basically "trivia" and nothing that will shake up your life much, but it's such an accessible read that I thought it was worth sharing with you. Nicolas Fränkel, who has been through our newsletter more than once over the course of its life, recently published his thoughts on all the things we lose when we are forced to go back to Java from Kotlin.

Nicolas while writing the post, I am not making it up

The text itself is not something special (there is no shortage of such, or even much more in-depth comparisons on the web), but Nicolas' conciseness and lightness of writing are its advantages. You can get through the whole thing in just a few minutes, and the author focuses on the real "Developer Experience" - those functionalities that you really miss every time you sit down to Java. And I have to admit that this short argument about such trite topics as generics and nulls gives us the ammunition to convince someone to give Kotlin a chance. In my bubble, Coroutines were always the feature that encouraged people to migrate, but given how few people write real concurrent code without relying on constructs like @Asynchronous annotations, it's the fewer bugs due to non-mutability or the ability to get around handicapped Java generics that might be a much better argument.

So if you want to convince someone to give JetBrains language a chance, I think Nicolas' publication is worth reading.

3. What was the migration to Java 11 like at a company like LinkedIn?

There's a lot of talk about how the bigger the company, the more they procrastinate on getting new software versions into production. Additionally, quite a few people claim that, in fact, 8 is "good enough" - in the sense that all the changes that have been introduced since JDK 9+ turn out to be so small that all the migration effort simply isn't worth it once. But no wonder - in large companies, the migration process is not always painless. Therefore, it is always interesting to read analyses of how such a process is carried out in other companies. Hardly anyone wants to write about such "trivial" things as Java migration. LinkedIn’s article (similarly to the advantages of Kotlin) takes the opportunity to throw in such an "obvious" thing, which in practice is not so obvious at all.

Nothing is simple when a company has 1000+ employees

From LinkedIn's text, you'll learn quite a bit about the improvements that the new Java brings - especially about Garbage Collectors, which may have escaped your attention, due to how "iterative" the patching process was over the last few versions. A lot of space was also devoted to less obvious problems, such as the fact that some JavaEE APIs have spread across many large codebases. From my perspective, however, the most interesting aspect covered was how difficult it is to maintain a dependency tree having different JDK variants, especially those from the pre- and post-module world. As in the case of the Kotlin text above, the whole thing turned out to be much more interesting than the title told you to expect.

I recommend it. After all, it is this unique opportunity that no one will be alarmed by the fact that you read LinkedIn during working hours.

"Yes, boss, I'm scrolling through LinkedIn to find out how to install the new Java".

And for you what's a good reason to rewrite to the new Java?