Java 14 GA
jdk.java.netNew features already discussed in https://news.ycombinator.com/item?id=22477629, but now it's GA.
> Remove the Concurrent Mark Sweep (CMS) Garbage Collector
pour one out for the legend
I have done much Java since I moved to full time Python/Node/Go. Guess I should give a try now. The Helpful NullPointerException is certainly a exciting feature.
Wow, I'm still using JDK 1.8. I thought I was way behind until I looked up the release schedule: apparently they're pushing out two (major) releases a year now.
They're not major releases; in fact, the last major Java release ever was 9.
The way releases used to work for the past ten years or so was that after a major release, every couple of months there would be a bugfix/security patch, and every six months (for a year or more) there would be a feature release (that used to be called "limited update") with major new features (new GCs, new monitoring mechanisms etc.) but without spec changes to the language and libraries. This meant that all the changes that required changing the spec had to wait for the major release. This had several bad implications. Most if not all of the spec changes were no more disruptive than the changes in the feature releases, but they had to wait for the next major release -- a lot of changes delivered at once created an overall fairly large disruption. Also the major release had to wait for the large features, and people couldn't enjoy smaller ones. Finally, people wanted to get their changes into the next major release so they wouldn't have to wait another three years or more, so features were merged before they were fully tested, which meant that the .0 major release was noticeably less stable.
So, to make the upgrade process easier and cheaper, Java got rid of the major releases, allowed making spec changes in the feature releases, and, with the major releases gone, every feature release gets a new integer name. The result is a much more gradual process. Every feature release is about as big and only slightly more disruptive than the old feature releases. The releases are now much more stable because features are merged only when they're mature enough; there's no rush because if you miss a release, there's another in six months.
The ecosystem will take some years to adjust, but those who've made the transition to running in production on the current release (many still can't, as some tools haven't yet adjusted) report a smooth process.
You make it sound like the upgrading process is something to be savoured when for many it's the opposite.
Upgrading a code base because of language evolution is pure cost for most people. It's a relatively risky and almost zero-reward exercise for mature applications.
You've got 3rd party library/dependency drag, tooling drag (everything from IDEs to CI/CD pipelines), development effort for code changes or QA and testing resources. Your engineers have to invest time in learning about the language and library changes. Never mind that unless you do a total rewrite, you end up with an incoherent code base which mixes old and new styles.
All this busy work/effort could instead be applied to adding features, eliminating bugs, improving performance, etc. - changes that end-users actually appreciate or that add business value.
Java conquered the enterprise precisely because it was slow moving and stable and offered unparalleled backward compatibility. Pretty much, the very same reasons Microsoft windows conquered the business world. This is (was) Java's strength not the weakness you portray.
Let's face it, at this stage Java is never going to be "cool" again the way it was in the 90s. Trying to join the "move fast and break things" school of language evolution just makes it look like a middle aged person (I'm one btw) trying to be "hip" by emulating young teenagers in dress and speech. At the same time you're alienating your existing users.
Reducing the total cost of updates is one of the main goals of the new model. The new feature releases are just slightly more disruptive than the old feature releases, and the major releases are gone altogether. No more testing is needed for the feature releases now than was necessary for the feature releases under the old model, but in general, people were doing testing under some very wrong assumptions. Full regressions tests are necessary for a release of any kind -- including patches (in fact, the most disruptive releases in the last 2 years was 11.0.2 and 8u202). If you were lucky to get by with less testing, the change in how the feature versions are named shouldn't change matters for you. Overall, the effort required is reduced.
I totally agree with this. I have worked in stable, long term, revenue generating projects that relied on java and its slow stable releases. I now cherish that we could focus on features and not have a "Migrate to Java x.x" story looming upon us.
With NodeJs, its a semi-annual affair to move and migrate or face unexpected broken 'npm install' commands. Fix the tooling, fix CI/CD, ignore warnings, application upgrades now require installing newer Node versions, no backward compatibility guarantees of any kind. Its a fool's errand.
I hate to see Java go this route. I don't think this will end well for the Java ecosystem.
Java has had the six-monthly feature releases (which were called "limited update" releases, as opposed to major and patch releases) for many years, with names like 7u4 or 8u20. They also had a support period of 6 months. For example, the 8u20 feature release got two patches, names 8u25 and 8u31, and then 8u40 came out and 8u20 no longer got patches. But people are confused by the choice to give those releases a new integer name now that major releases are gone.
It is an extreme misunderstanding to think that Java does not have "backward compatibility guarantees of any kind." Backward compatibility is of the utmost importance (Java has never made breaking changes as big as Python or .NET have), but it is not absolute. It's never been absolute; it's just that while breaking changes were mostly accidental before (or to implementation details), Java now admits some changes to the spec. But note that those aren't the changes that people have noticed (the biggest ones were removing methods that no one used). The breaking changes that people notice are implementation changes that some libraries, due to technical debt, relied on. As more investment is being put into the JDK and it's changing more quickly, that technical debt is showing, but it's not because of breaking spec changes.
Yep, the new rapid-release schedule. Java 8 (grandfathered) and 11 are the current LTS branches, both of which cease getting any kind of support (read: security fixes) in 2024. Java 17 will be the next LTS.
It seems to be a trend in software that has existed for a while to exponentially increase version numbers (see also: Firefox).
It's a quite linear growth, not exponential
But the first few numbers went by much more slowly, right?
Exponential would be if they kept getting quicker. They've only gotten quicker once.
I assumed that this was due to more products dropping vanity versioning in favor of semantic versioning. Is that not what's happening here?
If you upgrade, jump directly to Java 11. That may or may not be easy. But it was easy for me.
After that there was no effort to upgrade to all subsequent versions, to this point.
If one is using OpenJDK is there any reason not to track the versions > 11 as they come out, short of the usual reticence to upgrading?
Each upgrade after 11 has had good reasons to upgrade.
More and more Java source language features that make your life easier by small incremental bits in each upgrade.
Java 7, 8, and 11 are the Long Term Release (LTS) versions, that are getting patched every 90 days. Support to 2025'ish for them. With 9+, all the other versions get a 6 month life span, with new features in each and heavy deprecation/dropping of older bits with each short term cut. 9+ is fairly backward compatible with each other. 8 to 9 required a bit of finesse for things like JAXB and other things dropped from the 'core' into external libraries.
At least our shop made it to JDK 11. Next LTS version is 17, which is a while out.
Well, Java 8 was released 6 years ago and is basically EOL now. We migrated to Java 11 during the fall and finally most third party libraries we use seems to work fully in Java 11.
Azul will provide free OpenJDK builds for Java 8 until March 2026. It's not EOL.
Amazon provides Corretto 8 maintenance until 2023 as well. It's been a drop in replacement for everything I've needed.
11 is the correct go-to version now. The small but high value language improvements definitely make it worthwhile.
Well, you are still up to date in what concerns Android Java, in fact more than what Android Java supports.
https://developer.android.com/studio/preview/features?hl=ru#...
Yeah, although depending on what you’re working on, you’d probably be interested mainly in the LTS releases.
We’re bundling an OpenJDK 11 with our product and while I’ll definitely play around with v14, I think we’ll only upgrade once v17 LTS is out.
Why would you want to use OpenJDK 11 instead of 13/14? I'm using 8 because it's the latest version working with Windows XP, but other than that, I don't understand why would anyone avoid latest stable version.
Because of LTS. I don't consider a new release every few months very stable, and updating regularly just creates churn for no realized value. Additionally, any LTS release is going to get more thoroughly attacked, vetted, and secured. Despite best efforts, minor GC and JVM quirks tend to sneak in here and there with new versions. Maybe it doesn't affect people who write Java directly, but other JVM languages tend to be impacted more directly.
All OpenJDK versions are created equal. Vendors provide LTS services for arbitrarily chosen versions, sometimes after the fact (Azul now offer LTS for 13, while Oracle and others have LTS for 11). There are several reasons to use the current JDK. First, if you don't have a paid LTS service, the current JDK is simply safer. There are about 20-50x more OpenJDK developers working and testing JDK 14 than JDK 11 (and those who work on JDK 11 are split among different projects: Oracle's 11u ≠ Zulu 11u ≠ Red Hat's 11u ≠ Corretto 11u), while some free LTS offerings backport a huge number of changes. Second, you get to enjoy some significant performance, footprint and serviceability improvements.
> All OpenJDK versions are created equal
Not really. If they were then jdk12u would not be [READ-ONLY] and jdk11u still open here https://hg.openjdk.java.net/jdk-updates
After two patches led by Oracle, there's a call for volunteers to see if anyone is interested in continuing an Updates Project. But the original version itself is not written with that intent (nor is it known in advance whether anyone will step up). You will find no mention of 11 being in itself special in any way here, https://openjdk.java.net/projects/jdk/11/ and anyone can start an Updates Project for any version.
I use LTS in my project, my project is an big enterprise product, sell to big companies and govs/banks, some customer have very strict control on security, e.g. In one of my customers, a big bank, there's a seperate secutiry team, the team scan my the servers with my product monthly, onces the scans found any security issue(generally they are CVEs), the securty team notify product team those security issues my be fixed in 2 days, or network to/from those servers will be blocked. So we got highest level support case. In my case, security fix for java is very important, and it's not a good idea to follow non-lts java releases(there's no overlap in java's minor releases).
OpenJDK 11 is a LTS release, 13/14 are not.
That's not really an answer. I understand that some people want to freeze in time and having problems jumping from 11 to 17 version, but I don't understand why do they want that. Is there any compatibility issues preventing use of Java 13, for example? I understand that migration path for Java 9 was not very clear because of modules, but that's not the case for Java 11.
I guess you do not work in an enterprise environment. There are many reasons to use LTS releases, stability and security comes to my mind first. 3rd party requirements are also important in this topic.
Non-lts is a risk because if something crops up that prevents upgrade then you are very quickly out of support, which also sort of forces you to actively keep up with and test beta versions. In comparison the LTS versions have plenty of overlap so you have good time to resolve any issues that might come up, and you have had three years to test with the intermediary versions so its less likely that there will be any big surprises.
LTS version is like a checkpoint. Its support will be long term, i.e. security patches will be released on them. The versions in between don't get support.
It's not always because of development reasons. There are administrators at the customer's side that favor everything with LTS in its name, because of security fixes and support. We are selling on-premises products. If this was a cloud solution, then LTS would not have mattered much for us.
Because OpenJDK 11 is a LTS release with updates until at least 2024
Compatibility with some tools is really the only reason I can think of. For another example, Checker Framework does not yet support 13.
By your nomenclature this is java 1.14
When are the Alpine builds getting GA status? The last release of Java to include a build for Alpine was Java 8. Ever since then the Alpine builds have been restricted to early access releases. In the meantime Microsoft has started providing officially supported Alpine builds for .NET Core.
At least, Azul provides Alpine builds. Maybe other OpenJDK distribs too, i don't know ?
Great news, although I know it's gonna be a while before it's a smooth transition to this version - definitely going to push for atleast one of our systems. Some features we needed in this one. e.g. helpful NPE messages