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, which is highly invested in Java, 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 Java 5.0 release in September of 2004 ushered in 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 backwards compatibility. Enterprises enjoyed a solid 13 years of low-risk, minimal-effort Java upgrades, which is great for enterprises averse to change.
Java 9, released in September 2017, disrupted this stability, however, 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.
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 public classes/methods, and the Class-Path. Granted, the Class-Path still generally worked as it always had, but the module system was now inseparably intertwined.
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.
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 6 months by Java 10; Java 10 would be obsoleted in 6 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.
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.
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 which poses non-trivial upgrade effort due to backwards 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 backwards-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.
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 6th 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.
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.
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.
During the Era of Stability, Java consumers became accustomed to lengthy 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.
Many organizations would download and use Oracle's JDK during the Era of Stability without much thought. Bu 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.
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.
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 trends regarding cloud native application, 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 backwards 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.
I watched things unfold during the Era of Uncertainty with quiet reservation, but now that we're firmly in the Era of Predictability, I find myself optimistic about the future of the JDK. The dust from Jigsaw's arrival is beginning to settle, the first New Era LTS release is finally here, and FUD surrounding the Oracle JDK licensing changes has started to dissipate as consumers realize they have plenty of OpenJDK options at their disposal. I am personally eager to move to Java 11; I hope to convince my organization to be eager, too.