Comment by valbaca
Comment by valbaca 9 days ago
I shudder to think the amount of thousands of engineering hours are spent in my FAANG to keep our Java services just running as-is with updates.
And now we're moving more to Typescript on Node...UGH.
Comment by valbaca 9 days ago
I shudder to think the amount of thousands of engineering hours are spent in my FAANG to keep our Java services just running as-is with updates.
And now we're moving more to Typescript on Node...UGH.
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.
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.
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.
I thought Java was robust. What's the hassle?