Hacker News Reader

Comment by devin | Hacker News Reader

After reading a lot of comments in here, there is one thing that always repeats itself in Java/JVM-related comment sections on HN. There are a surprising number of people who have an idea of what the JVM or Java used to be and have very little idea of what it is today. It is a very fit predator in 2026. Does it have its warts? Yes, but the substrate is extremely good.

View on HN

Agreed - you don't get great JVM takes on HN, it's out of fashion here.

Our work uses modern Java (26 w/ preview features - mainly for StructuredConcurrency), and it's fantastic. Do not regret it one bit, and that's coming from using both Haskell and Python at previous companies.

Many of us work on Java monoliths that started in the 2000s when it was in vogue and we still have to keep them chugging along on Java 8. Personally I'm familiar with all the new features that have come out in the last few years, but for my actual work, java is literally stuck in the past.

Any reason why? My entire company is on 21-25. Except for one project that decided to use sun.internal.* classes.

Paying back tech debt, being able to keep up with treadmills (even slow and smooth ones) is depressingly rare.

Yeah, that would be a more nuanced take. The comments I'm indirectly referring to are people who are literally unaware of these features and talk confidently as if they do not exist.

whats keeping you from upgrading?

In this sense, Java is already the next Cobol. I usually ask one or two questions about class loading in interviews (of senior Java devs), the younger ones are frequently stumbling upon these, and they don't even understand why I'm asking this. Good old Tomcat days, when you could run out of PermGenSpace if you weren't careful :)

Good news is, Oracle extended extended extended support for Java 8 will not last forever, and eventually - if you work in a regulated industry - the company WILL have to pull the trigger.

On the other hand, "where there is muck, there is brass", so a little bit of legacy can be beneficial for some.

> we still have to keep them chugging along on Java 8

There's something else amiss here. Compared to other platforms, upgrading Java, even on complex codebases, has never been a nightmare for me.

The problem in a large codebase is keeping consistency when upgrading.

I upgraded a codebase of approx 100 kloc from Java 7 to Java 8 a couple of years ago. As I didn't want mixed patterns for the same thing throughout the code base I replaced most of the loops with their streaming equivalent. I had the luxury of having the budget for doing so.

Mixing patterns of newer language features alongside older ones can make the code base hard to read.

Most don't even know there are plenty of JVM implementations to chose from.

Reply on news.ycombinator.com