Live data from Hacker News

All New Java Language Features Since Java 21

inside.java

51–60 of 130 posts

Re: All New Java Language Features Since Java 21

#51
post #10
post #4

I am a big functional programming geek. I am one of the few people on the planet who can honestly say I have been paid to write F#, Haskell, Clojure, and Erlang. I have spoken at FP conferences like six or seven times, and I have shit on Java for most of my career. And yet, my latest talk at Lambda Days basically boiled down to “Java 21 and later don’t actually suck anymore”, and I genuinely do mean that. Java 21 is…

I don’t use Java often, but many developers at my workplace do; they universally hate the new FP features.

I thankfully have not had to use Java for years, but at one of my first jobs after grad school I was hired because I had Kotlin experience and they were moving the code base away from Java.

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.

Re: All New Java Language Features Since Java 21

#52
post #4

I am a big functional programming geek. I am one of the few people on the planet who can honestly say I have been paid to write F#, Haskell, Clojure, and Erlang. I have spoken at FP conferences like six or seven times, and I have shit on Java for most of my career. And yet, my latest talk at Lambda Days basically boiled down to “Java 21 and later don’t actually suck anymore”, and I genuinely do mean that. Java 21 is…

> The biggest issue, though, is that Java programmers won’t use the new features.

My old CTO boss swore he wouldn't ever use annotations because they were too much magic for him.

"No! Writing out gobs of XML to configure Spring DI is the only way!"

Re: All New Java Language Features Since Java 21

#53
post #30

After trying out many languages at many places, I reached the conclusion that Java, as weird as it may be, is my favorite language. There were times I hated it, but turns out I really just hated messy, over-engineered legacy code and working in a gray cubicle at aging MegaCorps. The language itself is quite beautiful when used properly and with modern features. It just really needs a makeover and better tools.

I moved to a C++/.Net/Python shop after working with Java, and I honestly miss Java.

Re: All New Java Language Features Since Java 21

#54

Isn't there a textual version? Seems pretty inefficient to have a video that is basically a big list

Copied this from the video description:

JEP 395: Records: https://openjdk.org/jeps/395

JEP 440: Record Patterns: https://openjdk.org/jeps/440

JEP 394: Pattern Matching for Instanceof: https://openjdk.org/jeps/394

JEP 441: Pattern Matching for Switch: https://openjdk.org/jeps/441

JEP 409: Sealed Classes: https://openjdk.org/jeps/409

JEP 361: Switch Expressions: https://openjdk.org/jeps/361

JEP 456: Unnamed Variables & Patterns: https://openjdk.org/jeps/456

JEP 507: Primitive Types in Patterns, instanceof and switch (Third Preview): https://openjdk.org/jeps/507

JEP 512: Compact Source Files and Instance Main Methods: https://openjdk.org/jeps/512

JEP 458: Launch Multi-File Source-Code Programs: https://openjdk.org/jeps/458

JEP 511: Module Import Declarations: https://openjdk.org/jeps/511

JEP 502: Stable Values (Preview): https://openjdk.org/jeps/502

JEP 513: Flexible Constructor Bodies: https://openjdk.org/jeps/513

Re: All New Java Language Features Since Java 21

#55
post #29

Earlier quoted context omitted.

I view this largely as a symptom of the widescale “success” of the bloated J2EE app servers in the early 2000s to mid 2010s. Your Java version and dependencies were locked in and upgrading was a massive effort. A large group of developers stagnated on Java 1.4.2 and 5 and seemingly never updated their use of the language, even when moving to Java 8 and beyond. The legacy stuff keeps ticking along.

I kind of think thats backwards. I think the success of the abomination that we have decided to label as J2EE or Jakarta was attractive to intellectually unambitious Java engineers because it progressed so slowly. 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.

Sorry, but I don't think a preference for slow evolution is always because of laziness. What's wrong with wanting to keep improving on a skill instead of having to waste time relearning things every six months?

Software is rare among arts/crafts/whatever in that it is difficult to find nice areas of software to keep digging deeper into (as curious people do!) rather than having to move on to something new just when you start to be good something.

It's not even wanting to focus on depth instead of breadth, as the constant changes means you are barely able to keep using your older skills, so there is little actual breadth more like constantly moving between shallow pools of knowledge. Maybe it feels great to constantly be moving, but I do not see how it is productive or positive in any way for us.

Re: All New Java Language Features Since Java 21

#56
post #35
post #12

Earlier quoted context omitted.

The new features make the code easier to read. For example var: List accounts = List.of(new Account(1), new Account(2)); var accounts = List.of(new Account(1), new Account(2)); It just reduces visual noise and boilerplate that you already know. 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 defa…

There is about zero difference in readability of your two statements, rending var not useful. And 'var accounts = calculateAccounts(something)' is literally less readable, because now you dont see what exactly accounts is. Var statement speed up writing, then are either irrelevant or gets rewritten to types for better readability.

It is less readable because either accounts is named incorrectly or calculateAccounts is.

If it should be createAccounts, nothing is lost unless you have multiple account types in which case you would call it createUserAccounts, create adminAccounts etc.

Re: All New Java Language Features Since Java 21

#57
post #35
post #12

Earlier quoted context omitted.

The new features make the code easier to read. For example var: List accounts = List.of(new Account(1), new Account(2)); var accounts = List.of(new Account(1), new Account(2)); It just reduces visual noise and boilerplate that you already know. 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 defa…

There is about zero difference in readability of your two statements, rending var not useful. And 'var accounts = calculateAccounts(something)' is literally less readable, because now you dont see what exactly accounts is. Var statement speed up writing, then are either irrelevant or gets rewritten to types for better readability.

I agree, and I'm not sure how something like 'var accounts = calculateAccounts(something)' can be thought of as better in a code review setting. I suspect using "var" or equivalent will be considered a problem by most companies within the next few years.

Re: All New Java Language Features Since Java 21

#58
post #38
post #35

Earlier quoted context omitted.

There is about zero difference in readability of your two statements, rending var not useful. And 'var accounts = calculateAccounts(something)' is literally less readable, because now you dont see what exactly accounts is. Var statement speed up writing, then are either irrelevant or gets rewritten to types for better readability.

Var can help in maintenance. Change the return type of calculateAccounts and you don't have to modify this code (assuming that it duck-types out equivalently). That isn't necessarily a huge win: it does force a compile change that isn't obvious from the source. And a refactoring tool could have performed the code change automatically so it's not as big a deal as it might have been.

I would argue that it helps me when performing maintenance to see and correct where types may have changed. Not always, and sometimes it is busy work I agree, but overall I prefer it.

Re: All New Java Language Features Since Java 21

#59

Isn't there a textual version? Seems pretty inefficient to have a video that is basically a big list

Copied this from the video description: JEP 395: Records: https://openjdk.org/jeps/395 JEP 440: Record Patterns: https://openjdk.org/jeps/440 JEP 394: Pattern Matching for Instanceof: https://openjdk.org/jeps/394 JEP 441: Pattern Matching for Switch: https://openjdk.org/jeps/441 JEP 409: Sealed Classes: https://openjdk.org/jeps/409 JEP 361: Switch Expressions: https://openjdk.org/jeps/361 JEP 456: Unnamed Variables &…

JEP 456: It’s crazy how glad I am to finally get rid of all those “ignored” vars in my code.

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

to

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

Re: All New Java Language Features Since Java 21

#60
post #35
post #12

Earlier quoted context omitted.

The new features make the code easier to read. For example var: List accounts = List.of(new Account(1), new Account(2)); var accounts = List.of(new Account(1), new Account(2)); It just reduces visual noise and boilerplate that you already know. 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 defa…

There is about zero difference in readability of your two statements, rending var not useful. And 'var accounts = calculateAccounts(something)' is literally less readable, because now you dont see what exactly accounts is. Var statement speed up writing, then are either irrelevant or gets rewritten to types for better readability.

> var accounts = calculateAccounts(something)'

Where did I write this? It’s almost as if there’s nuance in programming.

Var helps when you’re duplicating information that is already known. Your example is clearly not that.

Post reply on HN