Let me start with an admission: it took me weeks to work out what to talk about for the Java issue of De Programmatica Ipsum. There is just so much to it.
I recently took a twelve-year old Swing app and—with no code changes and minimal project changes—compiled it on the latest JDK. It now runs on the latest Java Runtime Environment, and every JRE back to 2014’s version 8 (which is still supported for Oracle customers until December 2030, by the way). The previous version: no code changes, just built on an earlier JDK, worked back to at least 2004’s J2SE 5.0 release. So I could talk about the phenomenal compatibility and future-proofing of Java programming.
However, that Swing UI does not necessarily look the best, so I thought maybe I could talk about the embarrasment of riches available when it comes to designing user interfaces for Java software. The original, classic Abstract Window Toolkit (AWT) is still there, and still not deprecated, so I could make the UI out of native platform widgets. Then my code would be compatible back to the first-ever release of Java, back in 1995. Or I could use something more modern: JavaFX and Apache Pivot are the choices for working with marked-up UI files like Microsoft’s XAML, Apple’s Interface Builder, or Vue.js. A more Java-ish way to build UIs is Eclipse’s SWT with the JFace helpers.
If I am modernising, why would I limit myself to Java? The JVM ecosystem directly supports interesting languages like Clojure, Scala and Kotlin. And then there are JVM-native ports of Python, Ruby, Smalltalk, and others. That is before we even start on the possibilities when you switch to a modern runtime environment like GraalVM.
I could carry on. This has not been merely a fraction of the Java-based technology available, it has been a fraction of the Java-based technology I have used in the last couple of decades. We did not talk about build systems, about server technologies, about education environments, about developer environments, about mobile, about smart cards…
Because that is the real story of Java. Once the ownership questions had been sorted out by Apple’s Mac Runtime for Java dying out, by Sun versus Microsoft killing the (deliberately incompatible) Microsoft JRE, by Sun’s open-sourcing their own implementation to create the OpenJDK, we were left with the simple observation: the Java Runtime Environment is everywhere computers are (give or take), and the Java Developer Kit lets you do whatever your developers are interested in.
And all of that in a hassle-free, continuous way. No “ground-up rewrite” to support some new language the senior dev on your team insists is the next big thing: JVM classes all interoperate so you let them try their thing on the edges of your existing, well-maintained project. Some people see that as tedium: they observe code that is steeped in the 1990s design patterns phraseology, like AbstractSingletonProxyFactoryBean, and see this as a sign of a staid technology, beloved of managers but not deserving serious technical interest.
Meanwhile, others see signs of success. That code (actually from 2006) is still there because, well, it is still there, because its authors did not get distracted by the shiny shiny and get bogged down in another rewrite, because as manufacturers and markets came and went, the Java runtime was still there, and the bytecode could still execute.
Some of the people who do not use Java have good reasons. Many of the “write once, run anywhere” people are getting the same value out of Google’s Chromium runtime environment. Others have hitched their carts to a particular vendor’s horse and get more support (from the vendor and the associated community) by using that vendor’s tools. But for many people, the Java Runtime Environment represents the most widely-adopted computer ever designed, and the wealth of technologies available in the ecosystem represents a broad guarantee that when they reach for “the best tool for the job”, it is available for their platform.
Photo by Anni Denkova on Unsplash
