Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java 14 GA

jdk.java.net

Post reply on HN
Print view View original

21–30 of 45 posts

Re: Java 14 GA

#21

Post by StreamBright »

vbezhenar wrote: post #16
enitihas wrote: post #12

Earlier quoted context omitted.

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.

Re: Java 14 GA

#22

Post by pron »

commandlinefan wrote: post #2

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.

Re: Java 14 GA

#23

Post by pron »

ilikehurdles wrote: post #19
vbezhenar wrote: post #10

Earlier quoted context omitted.

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…

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.

Re: Java 14 GA

#24

Post by oftenwrong »

vbezhenar wrote: post #10
p2detar wrote: post #8

Earlier quoted context omitted.

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.

Compatibility with some tools is really the only reason I can think of. For another example, Checker Framework does not yet support 13.

Re: Java 14 GA

#25

Post by 120bits »

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.

Re: Java 14 GA

#27

Post by heelix »

commandlinefan wrote: post #2

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.

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.

Re: Java 14 GA

#28

Post by _old_dude_ »

tofflos wrote: post #7

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 ?

Re: Java 14 GA

#29

Post by rmrfrmrf »

snazz wrote: post #11
chungy wrote: post #3

Earlier quoted context omitted.

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).

I assumed that this was due to more products dropping vanity versioning in favor of semantic versioning. Is that not what's happening here?

Re: Java 14 GA

#30

Post by zokier »

vbezhenar wrote: post #16
enitihas wrote: post #12

Earlier quoted context omitted.

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.

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.
Post reply on HN