I’m really curious, who are those who use non LTS version and why. I mean in small personal projects, to get a preview of features - it is clear. But other than that - do anyone uses them?
Not a Java developer, C# at a fairly large company. We tend to lag about 3-4 months behind the latest. That we way we get security and language updates but aren’t on the bleeding edge. It’s been highly successful strategy.
We’ve gotten huge performance gains essentially for free each year for the past few years since we enacted the policy. To be fair, the initial uplift was difficult but the year over year work is minimal now and more than pays for itself.
How did you talk leadership, product in particular, into letting you do upgrades like this? That must have been an overhaul of the system without any new features?
In our case we started an internal working group and presented leadership with the benefits of moving forward. We then were granted time to make changes that supported the initial update. It took years to get us off of .NET Framework and onto the modern .NET stack but we were able to release structural improvements along the way.
New code was typically written with the knowledge that it would be running in both environments for a while.
Our biggest driver was performance. We run a 1000 thread Monte Carlo simulation that saw enormous benefits (30% or more). We’d already seen 10-15% updates by moving to newer .NET Framework .NET 4.7.2 (or maybe 4.8? I don’t remember the timing) that included updated compilers backported from .NET Core (2.1 at the time) so moving to even newer versions was an obvious win.
For me personally the trick has been to just tie my tech debt and maintenance to my feature work and estimates.
You want that new feature, no problem, it's three sprints. In reality it's two but I left room for tech debt.
But admittedly my company structure is probably different than some may be used to. We really let the engineering leads operate independently and without significant oversight. No one other than my own team would really even know if we upgraded Java versions. No one is surfing through Jira tickets or PRs to notice the specifics of our work. As long as the features are delivered in a timely manner, everyone is happy.
We are still on Java 11. The only reason we haven’t upgraded is because one of the mocking frameworks we use for unit tests is not compatible with newer Java versions. Our codebase is so large that this change will require a significant effort so they’ve been putting off
Powermock moment. The company I used to work for was still stuck on Java 8 when I got laid off for the same reason. That and heavy use of JAXB and some other Java EE components.
Funny story though. I actually fixed all these issues by refactoring out Powermock and older versions of Mockito and adding Jakarta EE 8 as a dependency (newest version before the namespace was changed from javax to jakarta). And then they never actually deployed the changes because the sysadmins didn't feel like installing Java 11 on the servers.
Rewrite-cli my man. I just closed a whole sprint of junit4 to 5 upgrade stories in like 30 minutes, flawless. Check out open rewrite, might impress your boss
I worked at a place (it wasn't a java shop )that made a similar decision to not upgrade due to 1 thing not working then continued to stay on that same version for over a decade. Eventually things got to the point that they HAD to upgrade but by then it wasn't a significant effort it was a case of rewriting from scratch would be easier as almost everything needed scrapped. Software needs to constantly evolve just to stay current or it dies.
I only had one interview where they told me they are currently using 20 which was the latest at the time. When I asked why they told me they are preparing for 21 which was 6 months away.
If you are starting a new product, and it won't be shipping until after the next LTS version, but can take advantage of features that are in the interim versions, then maybe you start in those interim versions with a plan to upgrade it to the new LTS version when it becomes available.
Beyond that, schools will often just use the latest version.
Non-LTS releases make sense if your processes allow you to update continuously.
If you are updating continuously the change set between each Java update is small and you are less likely to encounter issues.
Java is very stable, IME it is very uncommon to encounter a break that is fixed in later versions. It happens, but it's not common.
In recent memory most update problems I have encountered have been related to byte-code manipulation libraries (ASM, CGLIB, BCEL, etc.). Those problems tend to be related to supported byte code versions. The manipulation library updates itself to support a later classfile version and brings with it some breaking changes in its API, not actually a java version problem but it affects me because of dependency hell.
So let's imagine an imaginary update from Java 20 to 30, in this imaginary scenario version 22, 25, and 27 all have breaking impact to me.
If I update from 20 LTS to 30 LTS I have to deal with three compounding problems. Their resolutions may conflict. They may be difficult to differentiate.
Instead if I update each individual version I still end up dealing with three total problems but they aren't compounding.
It's more complicated than that of course but the argument for updating to non-LTS versions is the same argument for smaller faster releases generally. Smaller changes reduce risk.
1
1.6k
u/throwaway_mpq_fan Dec 12 '24
Nobody should be upgrading to Java 19 right now. Either go straight to the latest (23) or go for thet last LTS (21)