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

[careysub]

Well, the latest version of Confluent Platform community edition - a Kafka/ Zookeeper offering - only runs on Java 8. That would be the major reason, using code - either commercial or open source - that does not run on Java 9 or 10.

Then there is the puzzling short maintenance periods being offered for all post Java 8 releases. See for example the comments here. Moving to a new Java version that will be supported apparently for six months is very questionable for any enterprise. It appears that Oracle has some sort of scheme to make everyone (businesses, anyway) to pay for using Java going forward.

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.

Re:Why not migrate

[charronia]

If you want to migrate, all your dependencies need to migrate first. It's taking a lot of libraries some time to get on board with Java 9, especially since it uses a completely new class loading mechanism.

Re: Why not migrate

[the_B0fh]

Not when your idiot coders have things like "is jdk == version 8.123.456" in the code.

No one apparently knows how to do something like "is jdk >= version 8"

Re:

[kurkosdr]

Most companies have customers, Oracle has hostages.