
The future of Java and OpenJDK updates without Oracle support - kjeetgill
https://developers.redhat.com/blog/2018/09/24/the-future-of-java-and-openjdk-updates-without-oracle-support/
======
anta40
"Oracle recently announced that it would no longer supply free (as in beer)
binary downloads for JDK releases after a six-month period, and neither would
Oracle engineers write patches for OpenJDK bugs after that period."

Where can I found Oracle's official statement about this issue?

~~~
bilbo0s
In my own opinion, people are getting a bit upset over nothing. But you can be
the judge.

Here is a pretty good write up on everything that's happening:

[https://www.azul.com/eliminating-java-update-
confusion/](https://www.azul.com/eliminating-java-update-confusion/)

There was enough concern about all the FUD people are throwing around that
Oracle took the step of providing a more visual explanation a long time ago.
It's here:

[https://www.youtube.com/watch?v=YauqubC8FKM&feature=youtu.be...](https://www.youtube.com/watch?v=YauqubC8FKM&feature=youtu.be&t=1049)

I mean, what's wrong with Oracle only supporting every OpenJDK for 6 months?

I'm a Unity user, so no dog in that race really. (Well, we make some game
server side stuff with java, but our big stuff is Unity). But it seems
completely reasonable to me. I'm probably missing something though, since the
internet outrage machine is in high gear. In all honesty though, it sounds
perfectly reasonable:

Oracle is basically telling you, "If you want more than 6 months of support,
buy a support contract. If you don't want to buy a support contract, then
you'll have to download the newest OpenJDK to get those updates and patches."

???

I'm probably missing something here since I'm not a deep java user, but what's
the problem with that release model?

~~~
kbutler
The problem has to do with various factors in Java and Oracle history:

\- Open JDK has not historically been a production-ready deployment. It was a
lower-performance, "reference" implementation, explicitly NOT recommended for
production deployments. This changed around JDK 9, but see the next point.

\- in spite of Java's attempts at backwards compatibility, migrating non-
trivial projects to new major releases of the JDK has always been painful and
slow. Many projects are still on (or recently reached) Java 8. For example,
Spring Boot released support for Java 9 just 6 months ago.

\- many Java applications are large enterprise applications (many
dependencies), and enterprises want stability and long-term support of
infrastructure components. It's likely that not all dependencies will get
migrated to a new JDK within 6 months, even less that the application will be
migrated, and that says nothing about rolling it out to production.

\- and production is when you really want security updates, etc. And Oracle's
plan is that the last scheduled security update would be a couple of months
before the next OpenJDK release, so you really only have ~4 months of a
supported, updated JDK release.

\- there have been various security problems with Java, even with Oracle's
support (particularly client-side, which is becoming less relevant)

So Oracle is moving from a slow-moving cost-free model to "hop on a rapid
upgrade treadmill on a release we've historically told you not to use".

So the simple answer seems to be "pay oracle for support".

\- Then you get into Oracle's [abusive? domineering?] licensing practices,
like requiring licenses for every CPU in a VMware cluster.

\- Some clients have been told by oracle reps to try enabling feature X, then
brought up for license violations because feature X is commercial-only.

\- Working with Oracle is problematic enough that clients don't even want to
enter into a conversation with them about the consequences of the JDK license
change for fear of getting on Oracle's radar.

The community appears to be stepping up, but there's still a lot of concern
about whether they will be able to provide production-ready, secure builds,
across the many platforms Java supports. (Notably, Solaris support appears to
be lacking...)

~~~
pjmlp
SpringBoot 2.1.0 already supports Java 11.

~~~
kbutler
Exactly. 9, 10, 11 in six months (total, not six months each), representing a
dramatic shift from the Java 8 history - and spring boot didn't support 9
until it was already reaching end of life.

Grails (built on spring boot) won't support anything higher than Java 8 until
end of 2018.

~~~
pjmlp
Is Grails even a thing still? On local JUGs around here, Groovy is only alive
thanks to Gradle.

~~~
zmmmmm
I think Grails has died under it's own bloatedness, and all the moreso because
frameworks like Micronaut [1] are showing that you can get all the advantages
of a full stack framework without the horrific bloat. I won't miss Grails
because I think that, a bit like Gradle, it is an antipattern use of Groovy -
needlessly applying its dynamic features where they are not even required and
hence resulting in code that is very hard to trace and figure out, and
sacrificing performance everywhere. Groovy is best when it's dynamic features
are used least, I find, at which point it hits a sweet spot that no other
language achieves for me.

[1] [http://micronaut.io/](http://micronaut.io/)

------
mabbo
At what point do we finally draw the line on Oracle and say enough is enough,
we're forking?

Oracle clearly seem interested only in trying to exploit Java developer and
users. Why are we still stuck to them?

~~~
kjeetgill
I get all the hate for Oracle the company, but they've taken the time to
systematically open source every closed source thing they've had: JFR, ZGC,
GraalVM (partially), and finally the crown jewel the TCK.

They've even been involved in getting the open community up and running.

I sincerely can't imagine what more you could want from a corporate steward.

~~~
CaptainZapp
_I sincerely can 't imagine what more you could want from a corporate
steward._

A different business model than suing their customers?

~~~
threeseed
They are only suing customers who refuse to pay licensing fees or remove
offending software.

Don't forget many of their customers are pretty dodgy/incompetent also.

~~~
hannasanarion
They demand their customers pay licencing fees to licenses they don't own,
like the Java language itself which is not subject to copyright under US law.

The suit against Google was filed within a month of the Sun acquisition, it
was part of their reasoning for buying Sun in the first place: so that they
can sue Java users and get tons of money for nothing.

~~~
pjmlp
Sun would have tried to squash Google just as they did before with Microsoft,
but they were out of cash, sadly as we could have gotten a proper JavaSE
mobile platform instead of the craziness of Android development and
incompatibilities with OpenJDK.

Gosling interview on "Oracle vs Google".

[https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be...](https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be&t=57m42s)

------
kjeetgill
TL;DR Andrew Haley is stepping up on behalf of RedHat and the greater OpenJDK
community to provide leadership for LTS branches of OpenJDK 8 and 11.

> The OpenJDK Vulnerability Group, with members from many organizations,
> collaborates on critical security issues.

Huh, I'd never heard of that before.

> There is also the question of back-porting important features from later
> OpenJDK releases ... While new features, particularly performance-related
> ones, are undoubtedly nice to have, our first priority must be to not break
> anything: we must remember that we are stewards of a very precious piece of
> software. ... each proposal will have to be taken on its individual merits,
> and I don’t think we can have a one-size-fits-all policy for such things.

This is so refreshing to hear. Especially after all the turmoil over the Linux
CoC, it's nice to just hear: we'll rely on my human judgment and that if my
peers.

All in all I think this is good news and well needed clarity.

------
vaer-k
> Some people might be worried that their chosen distribution will not build,
> test, and package OpenJDK correctly, but if you don’t trust your
> distribution to build packages, you shouldn’t be using it at all.

Can anyone say which distributions he is alluding to?

~~~
SloopJon
It's rhetorical. The point is that if you trust your distro with millions of
lines of code from Linux, GCC, and a thousand other packages, then you should
be able to trust it with one more package (albeit a big one).

------
kbutler
The title on HN is misleading by truncating the word "Support" from the
original.

Oracle remains the driving organization behind Java and OpenJDK. The change
that has everyone up in arms is the cessation of Oracle support for updates to
OpenJDK versions 6 months after release (no long-term support/updates of
OpenJDK releases)

~~~
sctb
Thanks, we've restored the “support”!

------
thefounder
People should use Go and forget all the licensing issues. Bonus: happy
developers!

~~~
solatic
Go hasn't had a history yet of breaking compatibility with earlier releases.
Wait until Go 2 comes out, then we'll see how much Google wants to maintain
long-term support. Two hints: it'll be at least as long as necessary for
Google to port all of its Go 1 code to Go 2, and it won't be much longer than
support for Inbox or Google Reader. And a further hint, Google will figure out
how to port all of its Go 1 code to Go 2 much faster than you think, and your
company will not be able to port its million-line Go codebase nearly as
quickly.

~~~
pkhagah
One of the stated goals of Go2 is forward and backward compatibility. We have
to see how well this pans out when Go2 is released.

> Go 2 must also bring along all the existing Go 1 source code. We must not
> split the Go ecosystem. Mixed programs, in which packages written in Go 2
> import packages written in Go 1 and vice versa, must work effortlessly
> during a transition period of multiple years. We'll have to figure out
> exactly how to do that; automated tooling like go fix will certainly play a
> part.

[https://blog.golang.org/toward-go2](https://blog.golang.org/toward-go2)

~~~
solatic
It's an admirable goal, and we'll see whether it works out in practice.
Remember, this entire thread is about JDK updates. Java also explicitly has
forward and backward compatibility as a design goal, but then sun.misc.Unsafe
turned out to be a bigger headache than most people thought, and upgrading to
Java 11 will require many companies to update core dependencies, and
unfortunately a lot of companies would rather pay for Java 8 support than put
in the maintenance effort.

Even if there's 99% compatibility, if upgrading requires anything more than
updating the compiler, even if it's just adding a runtime flag and the upgrade
effort should be minimal, you're going to see significant resistance from
companies with large codebases.

------
jokoon
Java stemming from one company in particular is one big reason I don't like
Java, on top of requiring a jvm.

At least with C++, there are several companies involved, and its inventor
doesn't work for one software platform in particular (herb sutter works at
Microsoft, that I will agree). I don't know how 'iso' Java is, but to me c++
is much more adaptable.

Java requiring a jvm makes things a little complex. Does the jvm offers
guarantees like c++ does? I trust c++ more, because once it's compiled, there
are much less uncertainties.

~~~
chrisseaton
> Does the jvm offers guarantees like c++ does? I trust c++ more, because once
> it's compiled, there are much less uncertainties.

This seems backward to me. C++ has a great deal of undefined behaviour, which
you don’t get in Java. And Java has had a memory model for years - until
recently nobody could argue their parallel code was correct on C++.

If you want guarantees Java seems like the better option.

~~~
jerven
Exactly! also on my current project I have tried out different JVMs and the
results where identical.

Oracle (HotSpot) GraalVM (also Oracle) Zing OpenJ9 ExcelsiorJET

Performance was radically different between them, but the answers where the
same (ok equivalent as this a whole lot of parallel code).

My co-workers can't even get their C++ compiler to be accepted by two
different compilers and it is not just them. Compiler upgrades are feared
events where significant effort needs to be put in.

While even the hard upgrade to Java9 from 8 was 3 extra commandline switches
on startup. For a project with 168 dependencies and more than 1 million lines
of code. Done in one afternoon, with the upgrade to Java 11 taking 3 minutes.
(needed to add java mail to the WAR/classpath instead of expecting it to be in
the JDK)

Upgrades from 5->6->7->8 where equivalent or simpler. Eleven years in two bugs
due to an upgrade. One a compiler bug in 1.7.45 an other not overriding all
the methods from abstract list in a list of string implementation that
uppercased on retrieval. Trivial compared to C++ upgrades.

