Winter Is Coming for Java Updates
azul.com
azul.com
https://developers.redhat.com/blog/2018/09/24/the-future-of-...
That branch is always moving forward. New features added, new bug or security patched, etc.
Now there comes points where you need to package the OpenJDK source code into a binary.
This packaging process is done by multiple different "vendors".
Now Oracle packages for free a release every 6 months. That package is the Oracle OpenJDK. If another vendor did a package it would be Other Vendor OpenJDK.
Now the idea of back-porting is basically a cherry pick package. Instead of packaging the latest commit. You cherry pick only bug and security commits and apply them to say the release 8 commit. That way, you don't introduce new features, only bug fixes. Then you make sure you didn't break anything compatibility wise.
The idea is that those should be easier to migrate to, since by leaving out new features, you limit potential backward breaking changes.
This cherry picking merge, which can be painful to do, because sometimes you may need to address weird merge conflicts, or even make some changes to the fix since you're trying to apply it to a earlier commit then it was built on. This is what Oracle now charges money for.
Other vendors also offer back-ported releases for money. Azul and RedHat for example.
AdoptOpenJdk is a new community initiative trying to do backported releases for free with volunteer work.
And Amazon Coretto is doing it for free, but hoping that by moving to their JDK package, you'd eventually end up using AWS.
1: https://docs.aws.amazon.com/corretto/latest/corretto-11-ug/p...
Even the article seems a little more FUDdy. As much as I dislike / don’t care for oracle, their JDK versioning approach reasonable. Commercial licensing for the special JDK, expensive support for the old versions, and open support for current openJDK version.
I don’t think even Go or Rails support major version minus 1 or 2.
"sharing your findings with the rest of the engineering community, hardening your patches in Amazon's production systems, releasing them as part of Corretto, and contributing improvements back to OpenJDK."
https://lensa.com/software-development-engineer-openjdk-perf...
11: https://blogs.oracle.com/java-platform-group/building-jdk-11...
12: https://blogs.oracle.com/java-platform-group/the-arrival-of-...
Absolutely not. The OpenJDK is the official reference implementation, and Oracle has open sourced everything important.
The only question is how quickly the various OpenJDK packagers will provide security updates. The Red Hat option looks very practical if you're a Red Hat user.
I'm curious how each packager is going to decide what version numbers they use for backported builds.
I do.
IceTea is one OpenJDK JDK? Azul is another? Does IBM still maintain a JVM and will that be another? What the hell is this thing:
https://hub.docker.com/_/openjdk
Is that Oracle's OpenJDK release, which is different from Oracle Java? Or is this the IceTea release?
Oracle's OpenJDK build is very similar to Oracle Java but comes without the support contract or the license fee. Amazon are apparently working on one tailored more to AWS, etc.
(edit: didn't realise it was the literal upstream source - probably best to ignore my comment!)
IBM still have their own VM, J9, and while they produces JDK builds that they misleadingly call OpenJDK, they are not. They replace the OpenJDK JVM (HotSpot) with theirs, but keep the standard libraries. So it's not OpenJDK, but it's a JDK that uses most of the OpenJDK standard libraries.
Azul have two JDKs. They have the proprietary Zing, which uses their own VM (which, in turn, is a modification of HotSpot, which they licensed, with their own optimizing compiler and GC) and the OpenJDK libraries, and the open source Zulu, which is an OpenJDK build.
I think IcedTea is also an OpenJDK build.
> What the hell is this thing: https://hub.docker.com/_/openjdk Is that Oracle's OpenJDK release, which is different from Oracle Java? Or is this the IceTea release?
Good question.
You can just use the latest OpenJDK. That's the open source version. But the enterprises want to use the Oracle version. Which they can, but they would have to pay for it. So, I assume, most of the hullabaloo is about Oracle charging for their JVM.
Essentially, for whatever reason, there are people who don't like open source. So they don't want to use the open source JVM.
We use OpenJDK11 currently. The reason we're buying support is because bug fixes and backports END for JDK11 once JDK12 is (already was) released. If you want security/bug fixes, you'll need to upgrade your application to the new JDK every 6 months. For a team like ours (~8) people, it's simply not viable for us to be in a state of continual upgrading. We wouldn't get anything else accomplished. Our job is to provide value to the business, not be stuck in perpetual runtime upgrades. Buying the license allows us time between upgrading JDK versions so that we can target jdk11 for new applications.
For quite some time after jdk11 was released there was also a prevalent opinion by some of the more senior members on the team that Oracle was going to be gimping the OpenJDK release in some way or another. Even after being shown that that wasn't the case we had _multiple_ meetings where it was discussed that we shouldn't migrate to OpenJDK because of bugs that "existed in there, that don't in Oracle build". This is most certainly due to historical reasons, and I don't blame them for thinking it.
I can't speak to why we don't rely on other LTS options, I was not a part of the meetings that decided our actions. Ideally, we would rely on something like adoptopenjdk, but the powers that be decided to pay Oracle instead.
(I know, politics. But also, sustainability.)
Any 'minor' change in a user application, font being a common example, can have a significant negative impact for an enterprise that has built workflows around that application.
After this happened with multiple oracle “bug fix” releases, we of course stopped upgrading as much as possible, spending days trying to determine if each security hole being patched in the JDK was actually an attack vector for this app.
We also implemented periodic “therapeutic restarts” on all app servers.
It was like running a critical server app on Windows 95.
Also, you can use the community packages, such as AdoptOpenJdk, which will offer backported fixes on old releases for a much longer period.
And then there is Amazon Coretto, which is free.
As well as Azul or RedHat, but those are mostly paid as well.
You need to upgrade to a new JDK every couple of months if you want to stay secure even if you stay on LTS. You are simply assuming that upgrading to patches is easier than upgrading to feature releases. I don't believe this is true, certainly not over a long duration.
The new feature releases are time-based and were originally meant to be called 18.3, 18.9, 19.3 etc. Don't be confused by the fact that eventually people preferred the Chrome-like version naming scheme to mean that the new feature releases are major ones; they are not. In fact, the probability that your application would break by a patch release and by a feature release is not all that different.
We want the feature release process to be gradual and cheapest overall. The LTS path is meant for those who for some reason need a less gradual process than either the feature releases or the old model.
Of course, as an Oracle employee, I value your business, and I hope you choose to buy our support (that includes more than patches) even if you switch to the gradual update process.
The culture for us leads to more problems imo. Tests aren't required. We have > 100 legacy applications (most C#, but some java). I'm currently working on porting a webapp developed 5 years ago, written on jdk6 (I think) using Hibernate 4.x.y, to java 11. There's no tests for the webapp. The majority of the code was written by contractors. I've removed hundreds (if not 1-2 thousand) of lines of commented out or dead code before I even started refactoring. In this case, which I agree is probably an outlier, updating takes too long. Or maybe I'm too inexperienced.
In my managers eyes, they see how long it's taking to migrate to JDK 11, and they don't want that for every new "major release" (12, 13, etc)
How long to manage from what version? There was one huge major version between 8 and 11 -- 9, the last one ever. So if you go from 8 to 11, then you're basically doing one major release, plus two feature ones.
> Tests aren't required.
That's unfortunate, because even patch releases can break your application (and possibly at a probability that's not significantly lower than that for a feature release, although they are both low). In fact, this happened in 11.0.2/8u201[1], which was possibly more disruptive than any of the recent feature releases. Both feature and patch releases require the same amount of testing on update. If someone thinks they don't, then they are very deeply misguided.
Getting support is good, but having an understanding of the platform is also good. Having good tests is probably better than both :)
[1]: https://www.reddit.com/r/java/comments/ba79hh/beware_of_comp...
First, Oracle has completely open sourced the JDK, for the first time ever. Instead of a JDK with a complex license, mixing both free and commercial features and containing field-of-use restrictions, Oracle now provides the JDK under a 100% free and open source license, or under a commercial license for those who wish to purchase a support subscription (and fund the development of OpenJDK).
Second, there are no longer major releases, and the new feature releases are similar to the old six-monthly "limited update". JDK 10, 11 and 12 are roughly the same size as 7u2 and 7u4, which also didn't get free security patches after six months. What's changed is the name given to those releases, and to make the updates cheaper and easier, they have been made more gradual, by allowing spec changes in feature releases. Not only do you get security fixes for free forever, but there are no more major upgrades.
So the main point of confusion is that some confuse the new feature releases with the old major releases, when, in fact, they are much closer to the old "limited update" releases. People see a new version number, see that that number is not freely supported beyond six months and panic, when, in fact, the old releases that were similar to the new feature releases were also not supported beyond six months. They themselves were considered "updates" to some major release, but major releases no longer exist, and the "updates" now get a new version number. See here [1] for a more complete explanation.
In addition, there's another new model, that allows organizations that for some reason need a much less gradual upgrade process than the new one -- and even less gradual than the old one -- and that is something that Oracle charges for. But because the JDK is now completely open source, other OpenJDK members have committed to backporting the fixes to provided a similar step-wise upgrade path for free.
(I work on OpenJDK at Oracle, but speak only for myself)
[1]: https://www.reddit.com/r/java/comments/bav1sy/winter_is_comi...
java.com is the website for "consumer-side" Java -- i.e. the desktop JRE. The JRE and "consumer Java" no longer exist (as they've been replaced by jlink), and so the website is out of date and largely irrelevant. I hope someone soon figures out what other use to put it to.
I am aware what OpenJDK is and who develops it, and I can handle the changes to our systems just fine, but I'm an engineer, not a manager. I can assure you that the confusion around Java is very real, as well as IT departments worrying about machines updating to a Java version requiring a commercial license.
EDIT:
I asked about the JRE autoupdater, and got this answer:
Before update, it will offer to change the license to personal use (or to get a commercial one) or remove the software. It will default to remove. You can also choose not to upgrade and not to remove and keep using an out-of-date version. And if you accidentally remove, you can still get the old free versions from the Java archives.
Thank you for asking! It all depends on the warning that is displayed, of course. I still think that our IT has a good point in blocking the update completely.
We have Java installed. As far as I know, we never told the installer if our use was planned to be commercial or personal. But in a few days, personal-use-installations will get a free update and commercial-use-installations will...
A) not get updates, through the updater using heuristics and mind-reading to divine that the installation is not personal?
B) get the update and thus be expensively out of compliance with the license?
C) have the updater present the problem to the end user and expect them to carefully consider the legal situation?
I think many people have assumed that the answer is B and are currently busy uninstalling Java everywhere, but if I understand you right the answer is actually C?
Is there more information on this anywhere? Most importantly, what is the correct official way to tell the updater ahead of time to keep the old version and never update? (We have a legacy application that uses applets.)
There is no longer a parasitic Java installation on my computer.
I've seen exactly zero sign of this. In fact, I think most _knowledgeable_ people are very happy with these changes.
Your IT department is clueless.
There are reasons not to use Java (such as it being legacy tech and the PITA that is using Spring and Maven when those are supposed to make life easier), but historic Java Applet vulnerabilities aren't one of them.
It's been a while that I've been on Windows. All development and ops have been on Linux the last couple years for me.
Thanks for clearing this up.
Anyway, the fact that you're using the updater means you're on Java 8. The five-year-old JDK 8 is past its free updates for commercial use. If you must keep using 8 (and continue getting updates) for commercial uses, you must either: buy support from Oracle (same as before for JDK 7 past its end of free updates), buy support from someone else, get OpenJDK builds from other organizations (like AdoptOpenJDK), or continue using an out-of-date version.
This has always been the case with old JDKs, except now you have a few more options than before. The best option is, of course, to upgrade to the current JDK (12), and keep getting free updates forever.
That option wasn't mentioned by the updater. :)
I don't know if that's true. I know the vulnerability group [1] has members outside Oracle [2], but I know next to nothing about that process. I'm told that nobody gets any advantage on security issues.
> They are also not releasing source for JDKs after 6 months.
What do you mean "after 6 months"? There are no longer major versions. Comparing the update schedule for 7 (a major release) and for 11 (a feature release) makes no sense. JDK 11 is more similar to 7u2 or 7u4, which also got security patches for only six months.
All fixes go into the OpenJDK mainline. What Oracle engineers won't be doing much of is backporting the fixes to old versions, which, again, aren't major versions. They won't be backporting much to 8 (which is a major release) now that it's five-years-old, either, but that's the same as under the old model.
> Therefore, users of non-Oracle supported JDKs will be exposed to a zero day attack between the time of Oracle's CVE disclosure/patch release and the time that their OpenJDK distribution creates, tests, and releases a patch. I would love to see these communities thrive, but the reality is that Oracle is strangling them in the crib by taking control of the most important support functions.
You're talking about users who choose one of the two new release models, and pick the one that's been designed as a paid service. If you're concerned about that, you can pick the other new model, which is not only free but easier overall.
Such altruism; Can they do this for the TCK? Why not? Maybe all of Graal then? That seems to be where many of the dev efforts went after some staff for those now-free, previously-closed components were either repurposed or let go. I don't mind a company trying to make money (granted, not a fan of doing it on the language itself), but we shouldn't pretend they are selfless by treating actions that other languages had long since done as special.
You think that large open source projects developed by hundreds of full-time engineers are meant to be altruistic? Spending ~$100M a year (that's my estimate; I don't have numbers) is not meant as a charitable contribution, and if it were, I'd rather companies contribute this kind of money to worthier causes than software.
> Can they do this for the TCK?
The TCK is provided free of charge to people who produce OpenJDK builds. It is not provided free of charge to people who produce non-OpenJDK JDKs.
> Why not?
Perhaps because this is still seen as another channel to fund all those hundreds of full-time developers who make this open source software. All open source projects of this magnitude -- Chrome, .NET, Android, Swift -- are also funded by various income channels. I don't think any one of those, including OpenJDK, is open for selfless purposes. That's just not how "Big Open Source" generally works. But it is a fact that Oracle open sourced the entire JDK, and many people think that's a very good thing.
Java is deeply engrained in much of enterprise software, which is slow and difficult to change. The licensing change was not given with nearly enough heads up for companies to properly assess their options and migrate to OpenJDK if they choose. From a user perspective, where it’s known that switching JDKs and updating major versions is often not a straightforward task, it sure does seem like this was carefully planned to make it too difficult to move off the JDK that just got a lot more expensive to use.
My company is dropping Oracle JDK entirely and moving to Open JDK, and over time transitioning off of java wherever possible directly due of this change. We are not a small company. It took several months just to figure out the scope of how widely the JDK was in use, we had to cut Oracle a hell of a cheque to avoid licensing issues, and we aren’t doing it again. We have a dedicated team assembled to move off of Oracle JDK now.
The general consensus of the Java leaders in our company is that this is a last ditch effort money grab by Oracle to leech money from Java, which was feared from the day that Sun was acquired.
I don't know what enough would be. This has been discussed and explained for at least a year.
> it sure does seem like this was carefully planned to make it too difficult to move off the JDK that just got a lot more expensive to use.
What? The change was that as of JDK 11, Oracle JDK and OpenJDK are the same software[1]. The same software that used to contain both free and commercial features, and that had field of use restriction is now 100% free and 100% open. If this is making it harder, I don't know what making it easier would be. If free is more expensive, I don't know what less expensive is.
> My company is dropping Oracle JDK entirely and moving to Open JDK, and over time transitioning off of java wherever possible directly due of this change.
Good, because that's what Oracle has been asking you to do[2]. Oracle JDK is now the name given to the same software sold with a commercial support subscription. If you don't want to buy support, don't use the package that includes it.
> The general consensus of the Java leaders in our company is that this is a last ditch effort money grab by Oracle to leech money from Java, which was feared from the day that Sun was acquired.
I am a bit concerned that the Java leaders in your company think that a money grab is taking a commerical offering and making it free. Oracle has now made the JDK 100% open source and free for the first time ever. To fund its development, it is also selling support for those who want it.
[1]: https://blogs.oracle.com/java-platform-group/oracle-jdk-rele...
I say good for oracle looking to want compensation for support. And thanks to oracle for keeping it open source.. and well..your comments on the matter actually feel clearer than some of the information put out by oracle themselves hehe..
Indeed.
I work on enterprise software, and we have to provide Java components for companies that require it. None of our customers want or can use anything past Java 8, and we have no plans on supporting anything past Java 8 until someone squeals.
InputStream in = Main.class.getClassLoader().getResourceAsStream(filename);
try {
OutputStream out = new FileOutputStream(file);
in.transferTo(out); // new in jdk 9!
out.close();
} finally {
in.close();
}Personally, though, I really dislike Java regardless of the version being used. I'm hoping that some day I'll be able to foist this aspect of my job off on someone else -- then I won't have to worry about it!
Among the repackaged OpenJDK offerings, Zulu is at the top of my list.