undefined | Better HN

0 points__jem4y ago0 comments

I got stuck in this conundrum at my previous gig as well, and think reached a very different conclusion than you. In short, while I’m skeptical of some of the degree of churn across modern software development as a whole, I’m not sure that this is actually an issue with the Java ecosystem, which has been, and I think continues to be, way more sensitive to backwards compatibility than almost any other ecosystem.

In some ways, this is just a consequence of a kind of evolutionary leap forward for many applications. We don’t deploy our WARs into application servers anymore, we try to pack a fat JAR, or maybe even a statically linked runtime, into a container. We rebuild the whole world on CI all the time. I mean, Java 8 has issues just respecting cgroup limits, which many a despondent ops engineer has discovered.

I think there’s still room for the 1M SLoC monolith even in this new world, but there are real benefits on the horizon for upgrading to Java 17 and beyond. We’ve reached a point where it’s just more expensive not to make upgrades a regular part of you development cycle. And, no one is stopping you from just staying on 1.8. I mean, I’m sure there are still decaying enterprises stranded on 1.3.

0 comments

KronisLV4y ago

Personally, i'd never let a single monolith grow that far. Having a problem component or two that could be left on JDK 8 until they die and are rewritten (which would actually be possible with systems that have clearly defined boundaries and smaller scope), while migrating everything else.

Sadly, i don't get that choice, nor do i get the choice to make the judgement call to leave the monolith on JDK 8 in the name of stability. But hey, at least i'm paid a bit of money for it, so i have some motivation to work on all of it to the best of my abilities, learn a bit more about the JDK internals, have a word or two to tell others about my experience before i inevitably burn out from the churn.

Personally, i do still think that Java is pretty good when it comes to stability and backwards and forwards compatibility, especially since tooling like Maven is actually pretty good when compared to the alternatives (well, the parent POM functionality is confusing sometimes, but oh well, it has its use cases). That said, JDK 8 to newer releases was indeed a generational shift (probably one for the better) and you see similar things with Spring Boot 1.5 to Spring Boot 2.X, those breaking releases are inevitable.

I only wish that the things blocking people from writing more modular systems would disappear over time, so that huge monoliths that are incredibly hard to work with wouldn't be such an issue. I'm not necessarily advocating for microservices here, since people tend to go straight from one ditch into the opposite one (multiple services per person, nightmarish service mesh, needlessly large % of the code being for shuffling data around, suddenly building a distributed system even within a single domain), but at the very least it would be really nice to have someone look at it and say: "Hey, this PDF generation logic looks really brittle and perhaps should be a service of its own." or maybe: "Oh, hey, we're serving our RESTful API calls and front end resources from the same application, maybe we should have a separate front end app, served through a regular web server?"

Then again, if nothing else, i always have the choice to choose where i'm employed, even though i don't feel like letting my coworkers down at the moment either.

dtech4y ago

In general you are right that the Java ecosystem is highly backwards compatible, but 9 is a bit of an exception. The module system breaks a lot more stuff than usual, and is the reason a lot of legacy is stuck on 8.