All New Java Language Features Since Java 21

> try (var ignored = CloseableThreadContext.put(…)) {

to

> try (var _ = CloseableThreadContext.put(…)) {

But does it though?

I've just taken a new job writing primarily Java whereas I was previously writing mainly python and typescript.

One of the first things I've noticed is how dead Java's ecosystem (Maven central) seems in comparison to other ecosystems like PyPI, NPM or Cargo.

(Also side note: I've published packages on each of these registries and the publishing process for Maven central is comically terrible! This has to be discouraging people from contributing to the ecosystem.)

Second, the more I worked with C# and visual studio, the more I hated it. It was pretty much the opposite with Javascript, typescript and even Java.

var items = new HashMap();

Instead of

HashMap items = new HashMap();

That's the point of var. It reduces noise a lot in some situations.

I've been a full time java developer for the past 7 years. Let me start by agreeing that I have very little interests in the functional "innovations" they added. They're fine, but most of my colleagues agree that code using streams or lambdas very quickly becomes harder to debug then if you just wrote the code with loops and.

That's far from true for every java feature though. Switch statements have been super cool, Green threads are a promising road out of the CompletionStage hell the children are dreaming of these days. "var" is a very nice way to reduce double typing ("Thing x = new Thing()" -> "var x = new Thing()") and also a nice way to avoid changes to unrelated files ("Thing x = getFoo(); f(x);" -> "var x = getFoo(); f(x)" means changing the name of class Thing doesn't require any change to the code) that's been helpful in a lot of cases.

    List<Account> accounts = List.of(new Account(1), new Account(2));
    var accounts = List.of(new Account(1), new Account(2));

Java 8 is also a slow and old runtime. It performs terribly in 2025. Here’s a quote from 2020 and the gap has only gotten wider [0]:

> JDK 8 is an antiquated runtime. The default Parallel collector enters huge Full GC pauses and the G1, although having less frequent Full GCs, is stuck in an old version that uses just one thread to perform it, resulting in even longer pauses. Even on a moderate heap of 12 GB, the pauses were exceeding 20 seconds for Parallel and a full minute for G1. The ConcurrentMarkSweep collector is strictly worse than G1 in all scenarios, and its failure mode are multi-minute Full GC pauses.

You’re doing a disservice to everyone by continuing to use and glorify it.

[0] https://hazelcast.com/blog/performance-of-modern-java-on-dat...

> Everything that came after isn't really memorable nor helpful, especially lambdas.

Lambdas came out in Java 8, along with the streams API, and the fact that you don’t think they’re useful more demonstrates to me that you don’t actually understand it, since nearly every language before and after Java has lambdas and nearly everyone agrees that they’re useful.

Reifying a bunch of temporary interfaces is not “more readable” than a lambda. A bunch of terrible nested for-loop logic is not “more readable” than the streams API.

> You mention "var", why would we ever want in Java to hold a variable that you can't read immediately what is the type?

Your IDE can show the type, but even disregarding that there are lots of cases where you have to write the type twice in Java and it just makes noise. It doesn’t make the code more readable.

> we don't want to follow the same route of other programming languages unable to handle gigantic and complex platform systems.

Burying your head in the sand and Ignoring improvements in the language doesn’t make you more able to handle complex problems. It actually does the opposite and that’s so plainly obvious that I don’t think you actually thought through the sentence before you wrote it.

Take something like virtual threads. Most Java programmers don’t use them and instead keep using an executor service incorrectly because they also never learned the difference between blocking and non blocking IO. For them, virtual threads would be strictly better because it properly parks blocking IO.

Ultimately, I guess I disrespectfully disagree that Java “peaked” in 2012.

* Performant and safe standard library. * batteries included * a good way to actually care about managing dependencies, during build and runtime.

Okay, you got your stuff, please everyone now let's care about the standard library and that it really good.

Dude, java 8's eol was 8 6 years ago, now. I have nothing gainst waiting a bit for "newer JDKs", but way too often the pattern is that teams use the oldest possible JDK and only migrate several months/years after the last possible vendor has sunset their support.

> Java 8 was the peak of development age for the JDK.

To me it looks it was merely the point where your stopped caring.

I can use my IDE to see the type if necessary.

> Everything that came after isn't really memorable nor helpful,

There are several improvements that are very helpful

One example is how multi line strings help me to read more clearly without the unnecessary string concatenations:

   var sql = """
             SELECT foo
             FROM bar
             WHERE last_updated > :lastUpdated
             """;

   String dayName = switch (day) {
      case 1 -> "Monday";
      case 2 -> "Tuesday";
      case 3, 4, 5 -> "Other day";
      default -> "Weekend";
   };

They’ll give half-hearted justifications that are usually reductive or just flat out lies [1], but ultimately it seems to boil down to new=bad.

The amount of terrible code I have had to debug because Java programmers haven’t figured out you can use queues is upsetting, because all they learned in university is how to use `synchronized` wrong.

[1] I have learned that nearly every time someone says their disgusting code is “faster”, even when they claimed they tested it, it is almost universally untrue when I write a microbenchmark to check it.

A few of the older developers also complained about the use of map, filter, zip, lambdas, etc being harder to read as well. Then a month or two later when they realized they weren't going away, it was an important part of the language, and just learned how to use them the complaints just one day stopped.

Except for when we had to touch Java code and it didn't make sense to convert it fully to Kotlin.

I think people here are really underestimating how intellectually lazy most people are at their jobs. HN selection-biased for a geekier crowd so a lot of my criticisms don’t apply to readers of this forum.

IntelliJ IDEA is genuinely great. It helps that they were the ones who developed Kotlin, and a fair bit of the actual language changes were gacked from Kotlin. (Or you could say "prototyped and shown valuable in Kotlin".)

They are still hampered by lousy nullable support.

You didn't ask, but Spring still sucks. It's not part of the language but it's a ubiquitous framework.

It turns out, though, it’s still good enough for sealed interfaces and the like; I don’t have too many issues with it, though that might just be Stockholm syndrome at this point.

Maven is terrible as always but Gradle is generally fine. I use IntelliJ community edition solely for Java and it works well enough for what I need.

It’s not like Java is going to replace F# for me or anything, but I do genuinely think it’s more fun to write now than it used to be.

A lot of Java jobs aren’t that though, especially internal applications. A lot of places are running Java 17 or Java 21 on all their servers, literally have no plans to ever support anything lower, but the engineers are still writing Java like it’s 2003. That is what’s maddening to me.

If you’re an engineer you should be able to easily read the code to see what’s going on. Most of the time the “magic” can be understood in less than 30 minutes and then it’s not magic anymore.

Beyond the IDE you also have to consider the build tools, package management, debuggers, profilers, static analysis tools, etc.

It’s honestly too much for an HN comment. But as an example, if I do open one of these awful projects at work and it uses gradle for example, intellij will understand that, import the project, get all dependencies, let me run any target with debugging or profiling, give me code coverage, etc.

What I actually haven’t used up to this point are VTs. I got a service that implements a job queue and it currently works flawlessly with scheduled executor pool. I’m reluctant to go with VTs before evaluating what implications that may have.