Hacker News Reader

Comment by oweiler | Hacker News Reader

Why? Java 11 is already leaps and bounds better than Java 8.

I'm in Security and 8 generates a lot of revenue for me :)

I'm not sure that it's inherently insecure, there is just a ton of old stuff in the ecosystem still chugging away.

Java 8 was before Oracle started with evil licensing terms and crazy language changes which allowed all kinds of alternative syntaxes.

Not the parent poster, but I can see why: IMHO, the best new feature for Java was try-with-resources (Java 7), and the second best new feature was all the functional stuff in Java 8. On the other hand, Java 9 started the introduction of several breaking changes (it took years before I stopped seeing updates to Java libraries to fix their compatibility with Java 9 and Java 11), so it can be seen why someone would think of Java 8 as the highest point of that language.

(For Java 9/10/11 in particular, there are several small enhancements, but nothing as earth-shaking as the changes we got with Java 7/8.)

IMO you're neglecting the thousands of improvements in the HotSpot runtime.

You can't use any of these thousands of improvements if your software is broken because it depended on something which was removed, or changed in incompatible ways. It can take a lot of work and time until it all works fine, even more when the breakage happened deep within a third-party library, and as far as I could see, there was a lot of these breakages early on the Java 9/10/11 cycle. IMO, it's worth it to make your software compatible with the latest Java LTS release, but I can understand why some people see it as too much work for too little gain.

There were some subtractions for a bunch of stuff that wasn't getting much love to begin with. They removed their JS interpreter which was based on rhino which continued being a side library the entire time that java added it to the Java runtime. The only personal break that had no remediation was a minor helper class in JMX that affected me. Pretty much anything that was removed has some library addition that can add back what was cut. Basically Java 6-8 added a bunch of library support things that were probably better maintained as a third party library to begin with. The module system usually means adding some security policy exclusions for popular libraries, but in general I get a very well performing JVM that feels like it optimizes the code significantly better than in previous generations.

They aren’t critical to most applications, and are invisible to most developers.

As a Java developer you should really set up at least some basic monitoring and perform load testing from time to time.

And even in the unlikely event you don't see any improvement with recent versions of the runtime, something like Spring Boot 3 requiring Java 17+ isn't exactly "invisible" in the Java world.

This is by far the biggest improvement to java in the last few years and plays a big role as to why a lot of different types of backend tools still are written in JVM based languages rather than switching it up. This said, hotspot still has some issues with taking full control of SIMD optimizations.

> as earth-shaking as the changes we got with Java 7

7 didn't introduce anything earth-shaking (just try-with-resources), lambdas were earth-shaking, just like records and switch expressions are.

Reply on news.ycombinator.com