3 ms·

"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

by anta40 8y ago

"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 8y ago
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&t=1049 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?
- kbutler 8y ago
  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.

by anta40 8y ago

bilbo0s 8y ago

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&t=1049 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?

kbutler 8y ago
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.