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

41–45 of 45 posts

Re: Java 14 GA

#41

Post by pron »

sh87 wrote: post #38
derriz wrote: post #34

Earlier quoted context omitted.

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…

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.

Re: Java 14 GA

#43

Post by [deleted] »

zokier wrote: post #30
vbezhenar wrote: post #16

Earlier quoted context omitted.

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

[deleted]

Re: Java 14 GA

#44

Post by p2detar »

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.

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.

Re: Java 14 GA

#45

Post by DannyB2 »

jghn wrote: post #36
DannyB2 wrote: post #17

Earlier quoted context omitted.

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.

Post reply on HN