> If you have a company with a ton of Java 5 code...
You are in deep deep trouble already, just process-wise. If you're making money hand over fist you might be able to afford to do that, but choice of language is not even on the radar in terms of what needs fixing.
Now, if you mean in terms of digging out of that hole... just upgrade to newer dependencies, newer JDK versions, etc. That's the way to better performance, better memory usage, better GC, better everything... and THEN think about the language you're using.
> You are in deep deep trouble already, just process-wise.
Code is usually a much smaller piece of company's business process than we developers like to think.
> If you're making money hand over fist you might be able to afford to do that
Here's the problem though: the vast majority of companies on the planet don't "make money hand over fist", they just have small to reasonable profit margins. And most businesses can't just risk losing what's already been working for a decade just because some developers want a new shiny thing every six months.
That's the reality which JVM and Clojure folks take very seriously, but is very often overlooked by younger people.
> Code is usually a much smaller piece of company's business process than we developers like to think.
I agree.
Btw, I think you inverted the meaning of my sentence regarding 'hand over fist'. I was saying that staying on an old version is asking for trouble and is going to cost a lot more than upgrading.
> That's the reality which JVM and Clojure folks take very seriously, but is very often overlooked by younger people.
Ah, the irony of being called young because of a comment I made :). I'm an old hand at this point.
FWIW, my shop also stayed on JDK 8 for a bit longer than we should have, but that was largely because of upstream dependencies. We're currently on JDK11, but again just because there are some upstream dependencies that are holding us back from JDK17. (It's mostly to do with the infamous module system change. It's a good change overall, but some projects have been super-slow to adapt.)
These are very good points. The programming language used is a tiny sliver of the pie chart required to run a profitable company. The entire “technology” portion of that pie chart is still only around 20% (at best) of a profitable company.
You are in deep deep trouble already, just process-wise. If you're making money hand over fist you might be able to afford to do that, but choice of language is not even on the radar in terms of what needs fixing.
Now, if you mean in terms of digging out of that hole... just upgrade to newer dependencies, newer JDK versions, etc. That's the way to better performance, better memory usage, better GC, better everything... and THEN think about the language you're using.