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

31–40 of 45 posts

Re: Java 14 GA

#31

Post by topspin »

vbezhenar wrote: post #18
TravelPiglet wrote: post #5

Earlier quoted context omitted.

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.

Re: Java 14 GA

#32

Post by zokier »

pron wrote: post #23
ilikehurdles wrote: post #19

Earlier quoted context omitted.

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 thos…

> 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

Re: Java 14 GA

#33

Post by pron »

zokier wrote: post #32
pron wrote: post #23

Earlier quoted context omitted.

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 thos…

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

Re: Java 14 GA

#34

Post by derriz »

pron wrote: post #22
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 wi…

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.

Re: Java 14 GA

#35

Post by snazz »

the8472 wrote: post #14
snazz wrote: post #11

Earlier quoted context omitted.

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?

Re: Java 14 GA

#36

Post by jghn »

DannyB2 wrote: post #17
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.

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?

Re: Java 14 GA

#37

Post by zikani_03 »

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

Re: Java 14 GA

#38

Post by sh87 »

derriz wrote: post #34
pron wrote: post #22

Earlier quoted context omitted.

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 wi…

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 tes…

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.

Re: Java 14 GA

#39

Post by songco »

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.

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

Re: Java 14 GA

#40

Post by pron »

derriz wrote: post #34
pron wrote: post #22

Earlier quoted context omitted.

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 wi…

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 tes…

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