1. 38

  2. 10

    Huh. I didn’t realize Java is going the Firefox/Chrome model of releases.

    Overall if you have good unit tests in your software, this shouldn’t be a big deal. Update to Java x, run sbt test or gradel test or whatever, update your test-running CI container to java x, let it run there, update your production Dockerfiles to java x, deploy and check your integration tests.

    Oh you don’t have a lot of unit tests? .. wait, you don’t have any unit tests?! … Well it will probably just work .. have fun!

    1. 5

      I don’t think it’s that straightforward for everyone. It’s hard to measure the performance impact of changes to the JVM, as well as potential obscure bugs, from just unit testing. I think most big deployments and libraries will stick to LTS releases as a result, which isn’t that bad given it’s about the old pace of updates anyway.

      1. 6

        To support this point, for a specific example of a more obscure change in a JDK that caused programs to fail, see http://www.oracle.com/technetwork/java/javase/8u20-relnotes-2257729.html - it’s a long list but note this

        Collection.sort defers now defers to List.sort

        Previously Collection.sort copied the elements of the list to sort into an array, sorted that array, then updated list, in place, with those elements in the array, and the default method List.sort deferred to Collection.sort. This was a non-optimal arrangement.

        The consequence of changing to sorting in place (the optimal arrangement), is that programs which sorted in one thread and concurrently iterated in another are more likely to crash with this JVM than previously. Might be hard to test for that even in an integration test!

        Unit testing is dangerous because it gives inexperienced coders false confidence that changes are good.

      2. 2

        Huh. I didn’t realize Java is going the Firefox/Chrome model of releases.

        Well, at least Firefox has train releases + a long term release. Java doesn’t seem to have that.

        1. 11

          Didn’t the article mention Java 8 being a long term release?

          1. 13

            Yes, Java has LTS releases, currently 8 and then 11. http://www.oracle.com/technetwork/java/eol-135779.html

            1. 4

              Ah, sorry, I had missed the precise scheme. I thought 8 was LTS, as it was the last “old-fashioned” release.

              1. 1

                Note that Red Hat will support OpenJDK 8 after Oracle discontinues their support as they have with previous releases in the past; they commit to it up to October 2020: https://access.redhat.com/articles/1299013

        2. 9

          Everytime I see this title, I think Java 9 has a terminal disease.

          1. 2

            Django’s release model is similar, but they support the last 2 releases + LTS. This is the ideal scenario IMO, because it means that there’s a window where you can slowly transition.

            Especially in a project with many dependencies, having to switch over everything all at once is a major pain. We need a bit of leeway, otherwise it’s going to be super painful