Era Of New Java
As a resident Java Subject Matter Expert within my organization, I’ve been paying close attention to the happenings surrounding Java over the past two years: the modular JDK, the six-month release cadence, the growing significance of OpenJDK, and Oracle JDK 11’s new license.
I hope to help my organization appropriately navigate these changes by not falling woefully behind in the versions of Java used by ensuring our JVMs are secure and can be patched, and by not unintentionally violating any software licenses. Achieving this aim starts with educating other stakeholders, especially upper management. I’ve found it helpful to explain these recent happenings to a less technical audience by framing Java’s changes in a historical context — namely, in terms of “eras.”
The Era of Stability
The Java 5.0 release in September of 2004 ushered an important era in Java’s history. It brought significant changes to the language and its Standard Edition APIs (Annotations and Generics, primarily), a new versioning numbering scheme (and no more confusing “J2SE 1.X” branding that had existed since the late 90s), and most notably a lengthy period of stability. For 10 solid years, Java remained largely the same, with non-disruptive improvements being delivered in Java 6 and Java 7.
Oracle’s 2010 acquisition of Sun raised some stability concerns at the time, but the transition turned out to be fairly smooth for the JDK itself (not as much for MySQL, but that’s another story). Prior to the acquisition, the Sun JDK was the leading JDK implementation on the market, ahead of other implementations such as Apache Harmony and the IBM JDK. After the acquisition, the leading JDK was the Oracle JDK — same JDK, different name.
Java 8 brought about more significant language and JavaSE changes (specifically lambdas and the Stream API), but by and large, it was a continuation of the “Era of Stability,” thanks to Oracle’s extreme devotion to backward compatibility. Enterprises enjoyed a solid 13 years of low-risk, minimal-effort Java upgrades, which is great for enterprises averse to change.
The Era of Uncertainty
Java 9, released in September 2017, disrupted this stability, inaugurating the “Era of Uncertainty,” as I like to call it. Although the release was long-awaited, developers did not enthusiastically switch to the new version. This was for a number of reasons.
JPMS Was Newfangled
The “killer” feature, the Java Platform Module System (JPMS) also known as Jigsaw, shook up some well-established Java norms: the JDK directory structure, the existence of
rt.jar, the meaning of
publicclasses/methods, and the Class-Path. Granted, the Class-Path still generally worked as it always had, but the module system was now inseparably intertwined.
Deprecated APIs Were Actually Removed
Java 9 was the first Java release ever to remove API methods. Methods had been deprecated since Java 1.1 but never actually removed, leading many to believe that they never would. And despite the removed APIs being few and minor, it arguably gave organizations even more reason to stick with Java 8 for the time being.
Java 10 Was Coming Soon
Around the time of Java 9’s release, Oracle announced that Java 10 would arrive in March 2018. After being forced to delay delivery of Java 9 on more than one occasion, Oracle declared their intent to move to a fixed six-month release cycle. Java 9 would be obsoleted in six months by Java 10; Java 10 would be obsoleted in six months by Java 11.
During the “Era of Stability,” Java users enjoyed long periods of free public support. For example, Java 6 came out in 2006 and received free public support until mid-2013, two whole years after Java 7 was released. But given the limited lifespan of Java 9 (and 10), many organizations decided to stick with Java 8.
The Era of Predictability
Now that Java 11 has arrived as of September 2018, I argue that we are transitioning out of the Era of Uncertainty and into a new era: the Era of Predictability.
Regular Release Cadence
After Java 9’s announced release date was pushed back multiple times, it remained to be seen if Oracle could stick to their proposed six-month release cycle. Sure enough, Oracle has delivered three major releases since their announcement, right on schedule; few now doubt that Java 12, 13, and beyond will too arrive on time.
As an aside, some folks contend that these post-Java 9 releases are not “major” but rather “feature” releases. I disagree. I regard a major release as one that poses non-trivial upgrade effort due to backward incompatibilities/breaking changes. Old Era Java releases typically required minimal upgrade effort (the most effort I can recall expending was related to Java 5.0’s reservation of the word
enum). Since Java 9, however, the introduction of JPMS, the removal of APIs and/or modules, and the existence of “preview features” all lend themselves to backward-incompatibilities. So even though the totality of changes per feature release will be smaller than in past releases, the likelihood of some breaking change being introduced means that New Era feature releases are still worthy of the “major” designation, in my humble opinion.
Uniform Periods of Support
In the Era of Stability, major releases arrived at irregular intervals. For example, there were four-and-a-half years between Java 6 and 7, two-and-a-half years between Java 7 and 8, and three-and-a-half years between Java 8 and 9. Releases also had free, public support for inconsistent — and lengthy — periods of time (e.g. five years for Java 5.0, six years for Java 6, and three for Java 7).
In this new Era, the support story is much more regular:
- Every major release receives six months of free, public support from Oracle.
- During these six months, there are typically two patch releases (e.g. for Java 11, versions 11.0.1 and 11.0.2 have been released to date).
- Beginning with Java 11, every sixth release is designated by Oracle as a Long-Term Support release.
- This LTS designation is purely a support-related one — there is nothing technically different between an LTS release and non-LTS release in terms of production-worthiness.
- Oracle will not provide commercial support for non-LTS releases after their period of free, public support concludes
- Oracle will offer paid commercial support for LTS releases.
Consistency Among JDK Implementations
In the past Era, OpenJDK and Oracle JDK were two closely-related but different implementations of the Java Development Kit. Switching from one JDK to the other was not guaranteed to be seamless due to the presence of proprietary features that only existed in Oracle’s JDK, particularly in the areas of security and desktop development.
But as of Java 11, all of Oracle’s proprietary parts have been open-sourced, resulting in functionally identical JDKs. As far as I’m aware, every modern JDK implementation on the market today is built upon OpenJDK. This means, hypothetically, that Java users will get a highly consistent development and functional experience regardless of the particular vendor they obtain their JDK from.
Entering Into the Era of Predictability
Now that the first Long Term Support release under the new six-month release cycle has arrived, it’s time to seriously consider migrating to Java 11. But before doing so, there are some choices to grapple with and new realities to reckon with.
Understand Your JDK Support Needs
During the Era of Stability, Java consumers became accustomed to long periods of free, public support. They installed their Oracle JDK distributions and patched them as security updates were released, perhaps taking for granted that there would be more free security updates provided for years to come.
This is no longer the case in the Era of Predictability. Free, public support lasts only for six months for every Java release.
- If you intend on upgrading Java versions every six months — great! You can do so for free.
- If you intend to stick with a particular Java version for more than six months — great! As long as you’re OK with leaving potential security vulnerabilities unpatched due to the unavailability of free OpenJDK updates, you can stay with your chosen Java version.
- If you intend to stick with a particular Java version for more than six months — great! You’ll just need to find a vendor that will provide extended support for the version you’d like to use. More likely than not, you will need to adopt a Java version that Oracle designates as an LTS release (Java 11, Java 17, Java 23, etc.), although some vendors offer extended support for non-LTS releases. Azul Systems, for example, designates certain Java versions as Medium-Term Support (MTS) releases and offers support for them.
Select an Appropriate JDK Distribution
Many organizations would download and use Oracle’s JDK during the Era of Stability without much thought. But more consideration must be given in this new era.
If you plan to enter into a support agreement with some vendor, then certainly obtain your JDK distribution from that vendor.
If you plan to go the free (as in, “costs no money”) route, then pay attention to the license and select a JDK distribution that uses the GPLv2 with Classpath Exception license. Oracle offers two differently-licensed distributions of the JDK: “Oracle JDK” and “Oracle’s OpenJDK.” The Oracle’s OpenJDK is the GPLv2+CE one; Oracle JDK, as of version 11, now features a new license that, among other things, forbids the JDK to be used “for any data processing or any commercial, production, or internal business purposes other than developing, testing, prototyping, and demonstrating your Application.”
So, do not use Oracle JDK 11 (or later Oracle JDK versions) unless you intend on purchasing a support subscription from Oracle.
Understand the Implications on Desktop Applications and Applets
It’s been a long time coming but, Java 11 has killed off the Java Runtime Environment, that thing that gets installed separately when installing a desktop-packaged JDK (no, not the Yahoo Toolbar) or trying to view a webpage that uses Applets in an antiquated browser.
I doubt anyone is mourning the loss of Applets, because if you’re using them, then you’re probably using an outdated, insecure browser and would have no qualms using an outdated insecure version of the JRE, either.
Some may mourn the impact on desktop applications, but, truth be told, the concept of Java-powered desktop applications isn’t going away; it’s just that they need to be developed and delivered differently. As Oracle explains in their support roadmap:
Oracle does not plan to migrate desktops from Java SE 8 to later versions via the auto update feature. This includes the Java Plugin and Java Web Start. Instead of relying on a browser-accessible system JRE, we encourage application developers to use the packaging options introduced with Java SE 9 to repackage and deliver their Java applications as stand-alone applications that include their own custom runtimes.
In other words, don’t try to move your desktop Java application to Java 11 unless you rearchitect how it’s built and distributed; there will never be any JRE 11 installed on the desktop. Instead, you must bundle the JRE (that is, desktop-related modules of the JDK) with your now-standalone application. I think this is a positive change as it gives application developers more control over the version of Java used. Furthermore, the JDK is now modularized, so you don’t need to include pieces of the JDK that you don’t need, reducing the risk of security vulnerability exploits through your application.
Consider the Alignment of the JDK With the Application Team
Organizations that have not fully grasped the whole DevOps movement/concept may very well put the responsibility of providing and patching the JDK with the Operations team. Considering Oracle’s recommendations for desktop applications, the popularity of microservices architecture, and cloud native trends, seriously explore the idea of having the Development team be responsible for the JDK by having them deliver the JDK along with their application to Operations.
Since newer Java releases involve more backward incompatibility risk due to removed APIs/modules and whatnot, then, most likely, all Java feature release upgrades will require some amount of code or build system change. Do not assume that Operations can just install a newer JDK version and have your Java applications continue to run without issue. Also, considering the sophistication and variety of garbage collectors now available in the JDK (e.g. Shenandoah and ZGC), application teams will be able to experiment and finely tune JVMs more easily when they are responsible for the JDK.