Slashdot Mirror


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.

13 of 85 comments (clear)

  1. Why not migrate by phantomfive · · Score: 2

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

    --
    "First they came for the slanderers and i said nothing."
    1. Re: Why not migrate by Anonymous Coward · · Score: 2, Insightful

      A lot of effort sometimes. For example many libraries like spring require bytecode modification and that is bytecode version dependant. To update spring you might need to update other libraries too and some of them may have deprecated things you use and so on.

    2. Re:Why not migrate by careysub · · Score: 5, Informative

      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.

      --
      Starships were meant to fly, Hands up and touch the sky - Nicky Minaj
    3. Re:Why not migrate by shanen · · Score: 3, Interesting

      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.

      --
      Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.
    4. Re:Why not migrate by charronia · · Score: 5, Insightful

      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.

    5. Re:Why not migrate by CaptainDork · · Score: 2

      I think we're going about this all wrong.

      Oracle is not a "we."

      --
      It little behooves the best of us to comment on the rest of us.
    6. Re: Why not migrate by jonwil · · Score: 2

      Just use OpenJDK. Unfortunately for Oracle, the GNU General Public License prohibits Oracle from stopping anyone using OpenJDK for whatever they like as long as they comply with the license. And the "classpath exception" (or whatever it is) means you can use OpenJDK and you dont have to publish any of your source code, just the source code for OpenJDK and any changes you have made to OpenJDK.

    7. Re: Why not migrate by angel'o'sphere · · Score: 2

      Actually, no.
      While the parent is right, the class loading changed, because of the concept of "modules", you can still invoke the JVM on the command line and force it to use the old mechanism.
      However typical modern projects easily use hundreds, yes, several hundred, libraries. The project I'm working on right now is already in itself split up into about 100 sub projects and pulls in about 900 libraries. Mostly Apache or other open source stuff, a few dozen commercial products ...
      Of course we are only directly dependent on perhaps 100 or 200 libs, but those pull other libs (via maven dependency management).
      So basically everyone is waiting that the main open source products move to Java 9, so they don't have to recompile and host their own repositories.
      But technically recompiling should not be necessary, standard Java 8 compiled jar files should simply run out of the box on Java 9 environments.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    8. Re: Why not migrate by the_B0fh · · Score: 3, Insightful

      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"

    9. Re: Why not migrate by sloth+jr · · Score: 2

      I think it likely that Oracle would attempt to use its newfound "Java APIs are copyrighted" court finding to turn OpenJDK and competing implementations into infringing implementations.

  2. Re:Dear Oracle by Anonymous Coward · · Score: 2, Informative

    Why are you calling me sexist? I'm merely telling you the logic college administrators trying to boost women's enrollment in CS classes had decided. If you feel that is sexist, take it up with them, not me.

    >To reduce the intimidation factor, the course was divided into two sections — “gold,” for those with no prior experience, and “black” for everyone else. Java, a notoriously opaque programming language, was replaced by a more accessible language called Python. And the focus of the course changed to computational approaches to solving problems across science.

    >https://www.nytimes.com/2012/04/03/science/giving-women-the-access-code.html

  3. Re: by kurkosdr · · Score: 4, Funny

    Most companies have customers, Oracle has hostages.

  4. So, can I just jump to Java 16? by Volatile_Memory · · Score: 2

    Java 8 end-of-life is January, 2019. So, let's say I want to switch...
    Java 9 has already ended free support as of March, 2018. Can't go there.
    Java 10 free support expires September, 2018 (again, before Java 8). No need to go here, might as well wait for...
    Java 11 which won't even be available until Sept. 2018.

    --

    /**
    I have a "Zero Policy" tolerance.
    */