5 ms·

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

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 8y ago
SpringBoot 2.1.0 already supports Java 11.
- kbutler 8y ago
  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 8y ago
    Is Grails even a thing still? On local JUGs around here, Groovy is only alive thanks to Gradle.
    - zmmmmm 8y ago
      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/
  - vorg 8y ago
    > 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.
pron 8y ago
A couple of points: - 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-releases-for-java-11-and-later 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.

pjmlp 8y ago

SpringBoot 2.1.0 already supports Java 11.

kbutler 8y ago
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 8y ago
  Is Grails even a thing still? On local JUGs around here, Groovy is only alive thanks to Gradle.
  - zmmmmm 8y ago
    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/
- vorg 8y ago
  > 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.

pron 8y ago

A couple of points: - 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-releases-for-java-11-and-later 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.