31–40 of 130 posts
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.
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…
- how’s the environment? Build tools, dependency management, etc. it used to be a PitA back then. - how has the typing system and generics evolved to support this? Have they introduced any type of variance?
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 think that's a fair comment, but also there's this perspective: I first touched Java 1.1 in 1997 in college, and only for a semester. Then for the next 22 years never looked at a line of Java, working mostly in C++ and Python plus dabbling in FORTRAN for high performance stuff that needed to be written there. I generally consider my self not intellectually unambitious.
Then I moved to a Java shop who specifically needed high performance math (well at least as high performance as you can get in Java, which is actually pretty good now). But we stick to Java 8 compatibility because we have some BIG customers who require that because of LTS on Java 8. There are some nice constructs that would help make the code more readable and modern, but when you need to support people and actually make money you do what you need to.
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.
* no type level concept of a const object (ie, you can have a const reference to a List, but never a reference to a const list). this makes const-ness an implementation detail of the class itself! so frustrating that List:add() can throw depending on the underlying class.
* lack of tuples (and no, record doesn't count). this is just a syntactic sugar thing, but I really miss it from c++ and python.
* var is far less powerful than c++ auto.
in most cases, I actually prefer the syntax of c++, which is really saying something.
Earlier quoted context omitted.
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…
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…
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 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…
This is amazing news! Two questions for you: - how’s the environment? Build tools, dependency management, etc. it used to be a PitA back then. - how has the typing system and generics evolved to support this? Have they introduced any type of variance?
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.
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…
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.
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.
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.
Map myExtremelySpecificAndVeryLongTypeNameMap = myExtremelySpecificAndVeryLongTypeNameMapProvider.provide();