What does Long-Term Support mean?
nipafx news #91 — 12th of September 2021
Hi everyone,
I wanted to send this on Sunday. It’s still Sunday (where I’m at), so here it goes. Less than what I aimed for but the important parts are there: A thorough (I hope) discussion of long-term support and an invitation to come to Accento (now online and free).
I send this newsletter out some Sundays. Or other days. Sometimes not for weeks. But as an actual email. So, subscribe!
Long-term support for Java
Once you dig into it, support — short or long term — is a surprisingly complex topic. It involves the OpenJDK, various companies and their commercial offerings as well as volunteer projects and contributors, and often the same people wear different hats at different times of the day. It also involves money and fame, which makes it a touchy topic, too. To top it off, the term itself is pretty vague and means different things to different people.
That I work for Oracle doesn’t make things simpler, but this newsletter is my hobby: I write it in my own time and send it once it’s done. Nobody proof-read or fact-checked this, which means (a) I may be wrong about some things, (b) you shouldn’t make any decisions solely based on what I write (see it as input for further research), and (c) this is not Oracle’s position or any of my colleagues’ opinion on the matter (well, it might be, but I don’t know).
With all of that out of the way, let’s get into it. While reading on, keep in mind what I said about the vagueness of support — I’ll come back to it toward the end.
Support in OpenJDK
To start, remember that OpenJDK is a project and a code base, but no runtime or binary. You can’t ever run OpenJDK, you can only run somebody’s build of OpenJDK. For example, you’ll find Oracle’s OpenJDK build at jdk.java.net and Adoptium’s at adoptium.net. Here’s how the OpenJDK project manages its forks and fixes for any given release:
- the jdk repo is the mainline where all principal development takes place — it is governed by OpenJDK under Oracle’s leadership
- about three months before the release of Java N, the mainline is forked to the repo jdkN — it is governed by the OpenJDK release process under Oracle’s leadership
- a few weeks before the release, this repo gets forked again into the update fork jdkNu — this is the interesting one because …
- when version N is released, jdkN is archived and will no longer see any changes
That means, after N’s release, support for it happens in jdkNu. So who’s in charge of these update forks? For the first six months, Oracle leads the community effort and prepares two update releases N.0.1 and N.0.2, patched with relevant security patches and bug fixes. After that, it steps down, so it can focus on updating the next feature release, and another company or community can take up the mantle. For example, Red Hat took over jdk11u and Azul took over jdk13u and jdk15u. Other forks, like jdk14u, may see no further development.
Even with jdkNu in charge of fixing bugs in Java N, much of that work still happens in jdk. Bugs often exist in the main line as well and are usually fixed there first before getting merged into the relevant update forks. In fact, much of the work on these forks is carefully evaluating which bugs should be fixed and merge the existing fixes from the main line — this may be a as trivial as a simple cherry-pick but if the development lines diverged in the mean time, it may just as well be Proper Software Development.
Vendor support
First a little nomenclature: When I say vendor I mean any company or community that offers JDK runtimes for downloads, for example Amazon (with Corretto) or Bellsoft (with Liberica). Some of them have more than one offer on display: As mentioned, there’s Oracle’s OpenJDK build on jdk.java.net but you can also get Oracle JDK, which comes with a different license, support (that word again), and a bill (for use in production).
The aforementioned OpenJDK jdkNu fork can be the basis for the vendors’ distributions and I think this is common practice, but I don’t actually know. (Does anybody ship a JDK that isn’t based on these forks? I’d love to find out.) Either way, different distributions can differ in more than just their name. Some vendors may build straight from jdkNu but others may include more fixes (e.g. due to contractual obligations) or fewer (e.g. because a change’s impact on stability was assessed differently).
How far can distributions diverge? I don’t actually know. They all need to pass the TCK (obviously), so from that point of view, they’re all interchangeable. So I guess the differences are more minute, maybe limited to edge cases for stability or security? (You see, I’m guessing.) Speaking of divergence, it is up to vendors whether they want to share changes they developed in house with the wider OpenJDK community (Edit: That’s not true. Because the OpenJDK code is GPLv2 licensed, source code of JDKs shipped with that license must be shared if requested.) I assume there’s a competitive advantage in not upstreaming the work that one put in to jdk or jdkNu, but on the other hand there’s a shared interest in not letting one’s code base diverge too much from jdkNu.
What is support?
It’s time to take a stab at the heart of all this: What exactly does support mean? Unfortunately, there’s no universal understanding and a number of services have garnered that description in recent years:
- providing up-to-date builds of the relevant OpenJDK forks
- providing preview builds with latest fixes before the next update release
- triaging problems and giving advice in filing bugs
- working to merge existing fixes into relevant forks
- developing new fixes
- helping to debug production issues
- probably more…
(You could call some of that maintenance (as opposed to support), but I’d rather not open another can of worms.)
Of course these services can be offered on a voluntary, best-effort basis or as a written contract with SLAs and all that stuff. If you combine all that, support can mean vastly different things from “on a best-effort basis, we provide up-to-date builds and help triaging problems” to “you can call this hotline 24/7 to have a production issue fixed within 24h”.
It would be nice to go over all the various distributions and see which boxes they tick but I’m not the right person to do that. First, I don’t know near enough about the various distributions and second, as an Oracle employee it’s not my place to evaluate other community members’ offers. But I can try (!) to do it for the Oracle distributions:
- Oracle’s OpenJDK provides up-to-date builds for the first six months after release that contain various bug fixes and all relevant security patches. As lead of the update projects during this time frame, Oracle also triages bugs and develops many fixes. All this comes for free and on a best-effort basis.
- Using Oracle JDK for free in development (did you know you can do that?) offers pretty much the same deal. It may contain more fixes that Oracle developed for customers, though, and since it’s the same version those customers pay for, you can bet your ass that this goes beyond best effort. ;)
- The paid version of Oracle JDK (called Oracle Java SE Subscription) is bit by bit the same as the free development version but comes with a contract: You pay money, you get customer service, etc. I don’t know very much about this, so I’m not gonna dig into this. If you have questions, the sales team is there for you. :P Some versions also have long-term support (more in that below).
Note from the future: You can now use Oracle JDK for free in production for three years. Details on the latest Inside Java Newscast:
So whenever you read/hear about support, please keep this smorgasbord of options in mind and ask yourself (and probably the person offering support), what exactly is on offer and does your project/company need exactly that or less or more? Obviously, the company-internal table tennis high score board can get away with best effort for up-to-date builds wheres the flagship project that keeps the same company afloat probably needs more reliability.
Long-term support
With all of that out of the way, long-term support is pretty simple: It’s the same vague thing, but for a longer period of time. For which versions and for how long? That’s up for each vendor to decide on their own. Oracle decided to offer support beyond the first six months after release for the Oracle JDK versions 11 and 17 (plus some pre 11 but who cares about those amirite?) — that comes with the contract and stuff that I mentioned above. Most other vendors stuck to the same versions and offer their level of support (be it free or paid, best effort or contractually guaranteed, for builds or for SLAs) for them as well.
Note from the future: The Inside Java Newscast above also explains why the faster LTS cadence every two (instead of three) years.
Since there’s more interest in the LTS versions, these are also the jdkNu forks that other companies tend to lead after Oracle steps down after six months. And this is the only link between long-term support and what goes on in the OpenJDK project!
This is a very important aspect to understand: Within the OpenJDK, the concept of long-term support does not exist. If all you could do was read the specifications and documentation, observe the mailing lists and GitHub repos, you wouldn’t know what “long-term support” means. You might wonder why some of these jdkNu forks (and the ones with weird numbers, too!) see merges for so long but that would be it.
In summary, support beyond best effort and long-term at that are concepts that live beyond the OpenJDK in the desert of the real where money and companies exist. ;)
Java 17
I wanted to give you a bunch of links to great articles, videos, talks, and other sources on Java 17 stuff, but I didn’t get around to looking through my notes. Also, you’ll probably be swamped with Java 17 in the next week anyway.
There’s one highlight that I want to point out, though: the next Inside Java Newscast. I can’t tell you anything specific yet, but we have big news! Look for it around Tuesday morning (US west coast) or afternoon (Central Europe) on the Java YouTube channel.
Accento
Very briefly: We had to move Accento online (you know why) and in the process made it free. Join us for these amazing talks:
- Venkat Subramaniam: The Art of Simplicity
- Holly Cummins: Tradeoffs, Bad Science, and Polar Bears — The World of Java Optimisation
- Rachel Andrew: How to understand CSS
- Falk Sippach: Java 17 — Was erwartet uns in der neuesten LTS-Version?
- Peter Kröner: Advanced JavaScript Scheduling and Interleaving with Generator Functions
- Emily Jiang: Cloud-Native Application Development with MicroProfile
- Christian Schwörer: Supersonic Subatomic Mocking: How to test your Quarkus app with Kotlin, JUnit and MockK
- Gunnar Morling: To the Moon and Beyond With Java 17 APIs!
- Kenzie Woodbridge: Long-term Documentation Maintenance: Critically Necessary, Deeply Underappreciated
- Nicolas Frankel: A Change-Data-Capture Use Case: Designing an Evergreen Cache
- Rob Richardson: JavaScript Tests in Node, the Browser, and CI
- Halil-Cem Gürsoy: Die JVM in Kubernetes — Von Mythen und Killern
- Shai Almog: Getting Back to Sleep as Soon as Possible for the On-call Developer
See you there!
(Well, it’s online, so is it really “there”? And I won’t actually be able to see you very well either. So… “Read you online!” ? Not quite as catchy… I’ll work on that.)
