Beyond Java 8: The good, The bad and The Ugly.
Java is some times a controversial language. There are lovers of language and there are the haters. But they all agree that Java 8 was a revelation in itself. It gave us functional programming constructs to write concise and elegant software. It silently gave us CompletableFuture — another one of my favourites. One might even think why even upgrade beyond Java 8, its just perfect. A stat shows that 60% of the java apps are on Java 8 and I don’t blame them, after-all why break the things that are already working well. In this article I try to capture some of the common fear that I had when thinking to migrate to version > Java 8.
The Good.
Release Cycle:
Java is stepping into a 6 month release cycle. Which means that there are two versions every year. This can be daunting and contrary to what we were used to, like once in 5 years. But simply put they are adding very few features every release. Looks like the Agile has swept into Java creators as well. A quick language preview from IntelliJ sums it up I guess.
JShell:
Most VM languages had a Shell shipped along. Not java. Introduced in Java 9, it gives us access to most capabilities of java without writing a program in IDE. You may try out things before writing it. Hopefully my employer is not seeing what I trying in JShell, it would seriously dent my credibility as a senior engineer.
Language Features:
Java is moving fast and introducing many new language features. There are some features to die for — like var declarations, case classes and stream factory methods. One such list I saw contains even features from various versions, but it pretty much sums up where the language is going. Just copy Scala :-).
The Bad:
Licensing:
Lets lets talk about the elephant in the room. EvilCorp Inc who owns Java and one of my ex as well. Java is free, period. You need to pay EvilCorp only if you are using their JVM. All the language features are present in OpenJDK versions. Oracle promises certain optimization in their own JVM if you have $$ to afford it in production.
Deprecated Modules:
Like in any Java upgrade there are deprecated module for versions from Java 8. It would totally depend on your own application to see what are deprecated. Unless you are not using the Nashorn engine, which got deprecated, the upgrade should be straight forward with a few code changes here and there.
Non LTS Version:
While Java is moving fast every 6 months with a new version, it comes at a cost. If you are not on a LTS version, you would need to upgrade your app every 6 months. This could take some dedicated time. You could choose not to upgrade and run the risk of security bugs being exposed in your version. So “an enterprise wise” strategy could be to be on LTS version and fore sake all the cool features. We still can use the new language features but turning on release flags, but Java warns that it can be changed in future.
The Ugly
Jigsaw:
Java 9 introduced a feature Jigsaw for modularity. The feature is roughly analogous to OSGI Framework or at-least it is trying to solve the same problem. Despite Java pushing this down our throat as a de-facto, we can easily port an existing Java 8 application to Java 11 without breaking a sweat. The support for modularity in Java is not embraced by library creators yet. In the world of microservices, modularity may not play a big role. Last thing we want is another module in a microservice.
JLink:
Java creators made sure that they adopt Jigsaw. They thought we would not possibly use all of the Java classes while writing an application. JLink goes over your application and finds out what is being used and produces a slimmer JVM. This could possibly reduce your Docker build size. But in reality it did not work for me. We were using a version of Alpine Linux with Java as a container, which was highly optimized for size. The compressed JVM just wont run in the Alpine linux for reasons beyond me. So I had to be content with openjdk11:alpine-jre which was ironically was bigger than the jdk8 apline linux docker image.
LTS:
Some of these versions are tagged as Long Term Support(called LTS -not a disease). One version in every 6 release i.e. 3 years is LTS. As much as possible we would like to be on LTS version. Why, if there is a big security bug somewhere in Java, somebody will fix it and save the day. But not so much for the versions in between. Java 8, 11, 18 are on LTS. So we are kind of locked to a 3 year release cycle one way of the other.
Conclusion
I tried to classify my experience into good bad and ugly. Like in the actual movie, the good can turn ugly and bad can be good. This classification could be shuffled from some other person’s perspective. Nevertheless, the good wins over the bad like in any movie. No spoilers here.
