Live data from Hacker News

All New Java Language Features Since Java 21

inside.java

61–70 of 130 posts

Re: All New Java Language Features Since Java 21

#61
post #31

i would prefer it, if they improve and extend the java standard library and the tooling for libraries many people will tell you that the standard library is not as performant as it could be and does not have as many batteries as python and try managing your dependencies... that would be far more important than the next super duper feature IMHO.

> many people will tell you that the standard library is not as performant

such as?

Re: All New Java Language Features Since Java 21

#62
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…

Programming language is a tool. Java developers value stability and ease of understanding for the code. I've seen the nice features you complain that don't get used, reality is that nobody wants to waste time knowing them unless they are intuitive to use. Especially when are forcing to use newer JDKs. There is no value in solving a challenge in a way that only you understand or make others lose time trying to underst…

If I had to guess, I'd say that a vastly bigger problem in the world is legacy code written in decades-old obsolete and inconvenient language dialects than code that's "too new".

Re: All New Java Language Features Since Java 21

#63

I’ve worked in Java for over 20 years. Being the “lingua franca” of the enterprise is its biggest strength IMO, but it is also perplexing to me that it was able to do that in the first place. The language itself is not bad. The tooling around it is very good. But the codebases you encounter written in it, particularly in the enterprise, are often horrible.

> But the codebases you encounter written in it, particularly in the enterprise, are often horrible.

Not sure they are worse than other languages?

Re: All New Java Language Features Since Java 21

#64

I’ve worked in Java for over 20 years. Being the “lingua franca” of the enterprise is its biggest strength IMO, but it is also perplexing to me that it was able to do that in the first place. The language itself is not bad. The tooling around it is very good. But the codebases you encounter written in it, particularly in the enterprise, are often horrible.

Mind sharing why do you consider Java tooling to be good (and largely, what is good here)?

The reason I ask is that I recently had to join a Java project at my company, and having a background in Node/Rust/Perl/Lua and some C++, I found the Java tooling to be extremely unsuitable for my taste.

A simple example: there is no standard LSP server, and the amount of jumps required to have a working setup with FOSS tools and make it IDE-independent is just horrendous. In every other ecosystem I've worked with so far, it was pretty easy in the last 5 years: if you don't like IDEs, you can keep using your vim/emacs/helix or whatever and just embed a plugin or two, with LSP integrated -- and you're ready to go.

Java world felt complete the opposite, like you had to use/buy some commercial tools to start doing something.

Re: All New Java Language Features Since Java 21

#65
post #55
post #29

Earlier quoted context omitted.

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 y…

I am arguing that they aren’t improving their skills in any regard, including how to properly use the tools they already pretend to know. They don’t go “deep” or “broad”, they don’t learn anything more than what they were taught in university.

I have had to debug a lot of concurrent Java, so my opinions are skewed towards that, but I have seen cases where “staff engineers” label every single function as `synchronized`, who genuinely don’t know why you would use a queue, have no concept of thread starvation or fairness, when to use an atomic instead of a mutex, and genuinely do not seem to understand that for network applications it’s generally more important to figure out how to reduce latency than trying to choose the optimal hashmap or sort implementation. These aren’t arcane details that require a PhD in category theory or require being constantly plugged into hacker news, these are extremely basic things that these Java engineers do not know.

I think most Java engineers, like more professionals in general, are very bad at their jobs. I think Java just selection-biases higher than other languages for people who are bad at their jobs.

Re: All New Java Language Features Since Java 21

#66
The explanation on why Java lets you use unnamed variables to prevent accidental use during deconstruction, but those unusuable variables still getting initialized by calling accessors, is a perfect example why I dislike the way Java implements improvements.

Every single, logical step that led to this hidden performance problem makes complete sense, because every improvement had to be its own tiny, contained improvement, but the end result is that `case Foo(int _, String _, User _, int age)` will still call three getters _just in case_ you're abusing the language to add side effects to accessors.

Perhaps even worse is the explanation that follows: if you don't mess up your accessors, the JVM _may_ decide to not call those accessors at runtime. So now the language itself has this weird performance impact to maintain backwards compatibility, but at runtime that backwards compatibility _may_ not exist and provide you with a performance improvement instead, negating the whole reason why backwards compatibility was added in the first place.

I like the improvements to Java, don't get me wrong. It's no longer the JDK 1.7 language poor enterprise programmers are stuck with. But if the Java people had come together and worked this out as one single feature, rather than five different ones, we wouldn't have needed to remember edge cases/a code analysis tool to remind us that using this intuitive language feature _may_ actually has a 3x performance impact depending on the mood the JVM is in today.

Re: All New Java Language Features Since Java 21

#67
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 think Java makes people into bad programmers, but I do think it selection-biases for intellectually unambitious engineers. They learn exactly enough Java in college to pass their courses, and then get a job at a BigCo that doesn’t strictly require ever learning anything more than what they were taught in their “intro to data structures” course. I think that's a fair comment, but also there's this perspectiv…

Sure, I am not claiming that you have to use every new feature every day 100% of the time. Obviously there are cases where you can’t upgrade for legal or compliance or “customer is just being difficult” reasons.

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.

Re: All New Java Language Features Since Java 21

#69
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.

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.

This experiment has already been run with pretty much every language that isn’t Java or C, and I think most people have been ok.

Yes, code review is arguably worse, but most people who write Java do so with an IDE and the type is never unknown at that point.

Also, if your function is big enough to where the type of var is not very clear, it likely shouldn’t be passing code review regardless.

Re: All New Java Language Features Since Java 21

#70

I’ve worked in Java for over 20 years. Being the “lingua franca” of the enterprise is its biggest strength IMO, but it is also perplexing to me that it was able to do that in the first place. The language itself is not bad. The tooling around it is very good. But the codebases you encounter written in it, particularly in the enterprise, are often horrible.

> But the codebases you encounter written in it, particularly in the enterprise, are often horrible. Not sure they are worse than other languages?

Having now experienced such Java codebases for the first time in my 15 year career… no, the Java code is much, much worse. Over engineered and otherwise poorly written Java code is SO much worse than other over engineered code I have worked with.
Post reply on HN