Hacker News Reader

Comment by adhamsalama | Hacker News Reader

I thought Java was robust. What's the hassle?

Not OP, but typically Spring and transitive dependencies. Some package that you don’t even use is pulled in and has a CVE. Or you upgrade major Spring versions and the API changes underneath you.

I recommend Spring Boot, it provides a "blessed" set of dependencies that work with each other. When you want to upgrade, you just need to increase one version (the Spring Boot version).

if you don't pull in 50 jars to replace the "new" keyword (aka spring DI), then this ceases to be a problem

This Spring hater (me) thinks that's a fair summary. It also eliminates much of the safety the compiler can give you for free. You will only find out during Spring init, or even later, that your program is broken.

Have people considered frameworks implementing JAX-RS instead? Or does the breakage happen specifically in extensions to Spring?

The only inconvenience I have experienced upgrading a Quarkus backend is renaming javax.* package imports to jakarta.*. Hopefully the next major version requires just as little effort (if not less).

I am sure there would have been a lot more work if the project used extensions like the Kubernetes client. But overall, I have had the best experience with tools like Maven (for Java) and Leiningen (for Clojure). It helps to avoid libraries that hack or access JDK internals (e.g. Lombok, or ancient libraries using sun.* internal packages for reflection)

The main problem is Spring Boot and some other Spring projects like Security.

If you would use Spring MVC directly, it is very possible that one could upgrade Spring versions for many years with minimal or no changes at all.

However Spring Boot regularly breaks code. And given the fact that it's very popular, it means that any Java upgrade is pain. You need to rewrite code, sometimes a lot of code.

If you just use JAX-RS, probably simple Spring setup would suffice, but people usually want to slap database, security stuff and other things and everything is provided by Spring, so it's not apples-to-apples comparison.

I've been working with Java for the last decade and for the past 5Y used the latest LTS versions in a very regulated environment (we have very strict patch deadlines for most CVEs). Rarely we hit issues with migrating to different versions of our dependencies. The most painful one was a small API change in Spring that revealed that we were doing something very bad so it took me 1-2D in between meetings to investigate. It is true though that every few weeks we are hit by a new CVE and we have to patch a lib version, but TBH this is what I expect from a language that has so many eyes on it's ecosystem.

Java is fairly robust and plenty of libraries are very low-velocity.

JVM itself, however, has had several breaking changes recently. So a lot of organizations are stuck on an ancient version of the language.

Not really true imo.

I speak from the experience of supervised the upgrade of thousands of services from JDK8 to JDK17

There’s few quirks added but:

1. JDK17 will happily run JDK8 code without any changes 2. Most of the issues I observed were due to project jigsaw (and were resolved by adding —add-opens as needed)

I would expect 17 > 21 upgrade to have basically no issues as an upgrade in place

I hate Java but backwards compatibility isn’t one of the reasons why I hate it

This unfortunately is not true for large codebases. The language and the basic library are extremely stable, but the overall runtime is not. So the 8->17 switch resulted in lots and lots of regressions.

So companies either pay Oracle to maintain the old JDK8, or use something like Amazon Corretto. It's so bad that there are companies promising JDK8 support until 2031 at least.

And yeah, upgrades past 17 are easy.

> It's so bad that there are companies promising JDK8

Come on, that's absolutely not the reason behind. That just means that there are banks and such that still run goddamn windows XP completely firewalled off from the internet just because. Similarly, for some companies not touching that ancient codebase and just having it safely run worth the hassle and the money.

Java is the most backwards compatible language and it is not even a close competition.

> Similarly, for some companies not touching that ancient codebase and just having it safely run worth the hassle and the money. > Java is the most backwards compatible language and it is not even a close competition.

It's amazing to have two contradicting sentences right next to each other.

> Java is the most backwards compatible language and it is not even a close competition.

In competitions consisting of Java, PHP and Python, I presume?

In competitions of real world code in a language that has been in use for close to 30 years, and I can find a java 1.1 program that will both compile as source on the latest version, AND the original compiled version itself will run on a modern JDK as is.

And I assume this mythical 1.1 program does of course do a lot more than System.out.println and the reason that it took until recently, in part thanks to the Log4J fiasco, for 8 (almost 11 years old) to no longer be the most widely used version, was just superstition?

A lot of BigCo people's (myself included) perception of Java is tainted by the challenges of old, inherited code bases. Java has been ubiquitous for a long time, and it's not surprising to accumulate code bases that have been underserved maintenance-wise over the years. Updating dependencies on a Java 8 codebase isn't much fun, especially because semvar wasn't widely followed back in those days.

Reply on news.ycombinator.com