Oracle Sets End Date for Business Java 8 Updates (infoworld.com)

An anonymous reader quotes InfoWorld: Further clarifying its ongoing support plans for Java SE 8, Oracle will require businesses to have a commercial license to get updates after January 2019. In an undated bulletin about the revision, Oracle said public updates for Java SE 8 released after January 2019 will not be available for business, commercial, or production use without a commercial license. However, public updates for Java SE 8 will be available for individual, personal use through at least the end of 2020.

Oracle advises enterprises to review the Oracle Java SE Support Roadmap to assess support requirements to migrate to a later release or obtain a commercial license... Oracle advises developers to review roadmaps for Java SE 8 and beyond and take appropriate action based on their application and its distribution model.

Comments

Re:Why not migrate

[shanen]

Is there any reason not to migrate to the newest version of Java? Is any effort even required?

Sure. You don't need or even want any of the new functionality and you believe that the additional complexity has made the new version less secure rather than more. Even stronger reason if you think any of the new features are negative rather than positive. Effort is NOT the real question.

Too bad we don't have any such option.

I think we're going about this all wrong. Old versions should be supported as long as sufficient numbers of people are actually willing to pay for whatever support they require. If they want to deprecate an old version, the way to do it is NOT by arbitrary announcements of when the new version shall be shoved down your throat, but rather by rational explanations of the various new versions and encouraging the users of the older version to consider one of the new ones.

Now if there are too few users of the old version who are willing to pay for the costs, then that's a different question. In that case the old version may need to be more strongly retired, and the users may be obliged to make choices, but they might prefer to gather around an even older version that still does what they want, or they might want to go forward. It should be the users driving the versions based on their real needs, not the corporate cancer (Oracle in this case) driving things as part of the never-ending quest for infinite profit.

I actually think it should go down to a feature-by-feature basis. In particular, features and functions that have security considerations should be obliged to check for their own validity before executing, possibly becoming inoperable if the security threat is too high. In terms of providing more freedom, there should be options for similar functions that don't have the problems...

DSAuPR, atAJG.