
Java 14 GA - koozz
https://jdk.java.net/14/
======
koozz
New features already discussed in
[https://news.ycombinator.com/item?id=22477629](https://news.ycombinator.com/item?id=22477629),
but now it's GA.

------
whateveracct
> Remove the Concurrent Mark Sweep (CMS) Garbage Collector

pour one out for the legend

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

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

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

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

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

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

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

~~~
_old_dude_
At least, Azul provides Alpine builds. Maybe other OpenJDK distribs too, i
don't know ?

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

