1. 2

    The missing context here is that the SmartBear code review tool is a ponderous process orientated anachronism. Code review in a modern system like github or Phabricator is so much more ergonomic. When developers’ primary code review technique is to export patches to an external diff viewer, the code review tool is deficient.

    SmartBear has an exagerrated focus on defects. Software that is never used has no defect reports. Ideally a code review is a conversation that leads to better software - this tool inhibits that.

    1. 8

      Technical disagreements in other projects lead to people being excluded. On the other hand, the Linux kernel manages to embrace incredibly diverse goals and viewpoints - from tiny devices to amazing supercomputers. The cost seems to be painful interactions. It’s great that these discussions are happening as this cost might not be necessary and certainly should be reduced.

      Let’s not forget that the Linux kernel is one of the most successful and largest collaborative works ever created by humans. The humility of the kernel maintainers, who admit defects in - and seek to improve - their process, is an example of the excellence of the culture.

      1. 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. 6

          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