Where can I found Oracle's official statement about this issue?
Here is a pretty good write up on everything that's happening:
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...
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?
- 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...)
- OpenJDK and Oracle's JDK have been nearly identical for quite some time, and they are identical as of this week. So whatever differences once were between Oracle/Sun JDK and OpenJDK, OpenJDK now is Oracle JDK. (https://blogs.oracle.com/java-platform-group/oracle-jdk-rele...)
- Enterprises have had to upgrade a JDK every six months for many years, now. But whereas JDK versions used to be named 8, 8u20, 8u40 etc., they are now named 10, 11, 12 etc.. In the past, JDK releases were also not supported more than six months. Some are under the impression that each of those is a major version; this is false. In order to make upgrades easier, Java no longer has major releases (Java 9 was the last), however, all releases now have their version number incremented ("Chrome versioning", if you like). To make this possible, the restrictions of what changes can be done with each 6-month release, so that the transition between, say, 12 and 11 is not quite the same as between 8u20 and 8u40, but it is also not at all like that between 7 and 8 or 8 and 9 (and closer to the former than to the latter). In addition, companies that don't want updates but only security fixes can purchase support from Oracle.
Grails (built on spring boot) won't support anything higher than Java 8 until end of 2018.
Grails 3 is built on Boot but virtually no-one uses it. Websites using Grails have largely remained with version 2 and no-one's starting new projects in version 3, so I doubt the Grails backers will even bother to add Java 9+ support to Grails 3.
The Apache Groovy backers also seem to have given up on releasing a version 3. A few months ago, they pulled preview support for version 3 features from the upcoming Groovy 2.6. Since then, Groovy 3 has been stuck on permanent alpha version, with no-one in their project management committee showing any interest in moving it forward.