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.
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.
At my previous job some were able to change that by consistently using "modern" features of Java. It inspired others to change and eventually we ended up with a good code base.
Be the one to start the change by implementing new features using good code. This will give others "permission" to do the same. Also try to give soft suggestions in code reviews or pair programming of simpler ways to do it (don't push too hard)
At my current job all of us are eager try the latest features. We may have overdone it by abusing streams when a simple for-loop would be more clear. I hope we don't abuse the new stream gatherers too much :-)
I know I came off as a bit negative, but in fairness to them, they did more or less continue working on what I was doing using the newer Java 21 features, and after I got a few pretty interesting changes merged in some of the more junior engineers started using them too; particularly I was able to successfully evangelize against the use of `synchronized` in most cases [2] and got at least some people using queues to synchronize between threads.
It honestly has gotten a fair bit easier for me since I've been doing this for awhile; at my last job I was the most experienced person on my direct team (including my manager) and one of the more experienced software people at the company, so I was able to throw my weight around a bit more and do stuff how I wanted. I tried not to be a complete jerk about it; there were plenty of times people would push back on what I was doing and I would think about it and agree that they were probably right, but I outwardly rejected arguments that seemed to be based on "I didn't learn this in university so it's wrong".
I have had other jobs (at much bigger companies) where they were not amenable to this. I would try and use new features and my PRs would be rejected as a result, usually with some vague wording of "this way is faster", which I later found out was (as far as I can tell) always a lie.
[1] It is not hard to find my job history but I politely ask you do not post it here.
[2] I'm sure someone here can give me a contrived example of where `synchronized` makes sense but if you need mutexes I think you're almost always better off with a ReadWriteLock or ReentrantLock.
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.
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.
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.
- 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?
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.
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.
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.
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 everyone 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.
There is no value in solving a challenge in a way that only you understand or make others lose time trying to understand the logic.
Java 8 was the peak of development age for the JDK. Everything that came after isn't really memorable nor helpful, especially lambdas. You mention "var", why would we ever want in Java to hold a variable that you can't read immediately what is the type? That is a source of bugs and time waste to track down what object is being used.
I don't mind you are happy with all these changes, just remember that we absolutely don't care about them nor will make much of an effort because in the end of the day we don't want to follow the same route of other programming languages unable to handle gigantic and complex platform systems.
This isn't a competition to showoff who can apply new tricks, we absolutely don't care about functional programming. Java code must be simple and easy for anyone to read, that's it.
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...
Still glorifying it.
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<String, MyExtremelySpecificAndVeryLongTypeName> myExtremelySpecificAndVeryLongTypeNameMap = myExtremelySpecificAndVeryLongTypeNameMapProvider.provide();
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.
This reminds me of a developer writing in jRuby because "it was better". While he was in the company he'd still give support to his own works, after leaving nobody else wanted to pickup those "better" things and would prefer to write workarounds to the tool, it effectively became a black box that few could improve and even worse to test. As result, those portions had to be rewritten in proper Java so that we'd be able to deeply measure/test and improve.
Never again.
I’m in agreement that when the information isn’t in the rvalue that you shouldn’t use var.
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.
Ideally this could all be dealt with via tools. An IDE that shows whatever the user prefers, but is actually saving into a format defined for the repo.
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 do still really like it in the `var list = new ArrayList<String>()` case though.
Maintenance involves a lot of reading of unknown code. That is literally the situation where you are rewiting var to specific types to figure out what is going on.
Please point me to an objective measure of "readability" that holds for all people. And then demonstrate that your example is "literally" lower on that scale.
Drives me nuts because you really can only write code for those programs with an IDE that is prepared for the case. Try to edit the code directly from the github web interface and it won't compile.
> Drives me nuts because you really can only write code for those programs with an IDE that is prepared for the case.
Usually people have strict rules for that (e.g. pep8), and most text editors will do it for you with little configuration.
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.
var items = new HashMap();
Instead of
HashMap items = new HashMap();
That's the point of var. It reduces noise a lot in some situations.
Map<String, Integer> items = new HashMap<>();
There are valid use-cases for `var`, but IMO this feature should not have been added to the language, as it's too dangerous and most people won't use it responsibly.
For argument types you don’t have var, so methods that take in a map can stay abstract and you can still pass in the implementation-specific version into those without casting it to the interface.
ETA:
I guess I am trying to say that if you want to be abstract, they should be at the argument or properties level. Local variables should be used locally. I agree that generally speaking you should try and prefer using Map for anything shared across different parts of code but I am not convinced it’s bad to have var be implementation-specific; if your method is big enough to where swapping out implementations like this will take a lot of time, your method is probably too big anyway.
I also like the nudge it gives you to use only the higher level methods, rather than the ones specific to the subclass unless they're needed. That also improves flexibility.
Declaring a local variable as an interface to hide functionality so you can swap out functionality later is misunderstanding the fundamental theories around interfaces. Your variable should be whatever the function or method returns. If you want to abstract the type so it can be swapped out, create a function that returns an abstract type. Don’t tell the HashMap constructor it did the wrong thing. Now that I think about it, I’d recommend you use “var” in all cases, and not try to redefine the return values from a function.
You would like to use Map<Key, Value> items = new HashMap<>() since in general you do not want implementation detail leaking into contracts
* 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.
> 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.
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'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.
Switch statements got better. I'm also getting used to Paths albeit don't yet understand why File wasn't already good enough. It is difficult to find compelling reasons for upgrading the JDK since I know it will be hassle for everyone that later down the line has to install/run the product.
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 switch statements have improved code readability, at least from my personal subjective viewpoint.
String dayName = switch (day) {
case 1 -> "Monday";
case 2 -> "Tuesday";
case 3, 4, 5 -> "Other day";
default -> "Weekend";
};I agree with you on switches and do like the """ feature, thought. It was a real pain in the rear to include the multiple + "\n" back in the old days. This is a very clean and intuitive improvement.
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!"
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.
But you're right, cmd+clicking on the annotation just shows where the annotation is defined, not where the behavior is implemented.
What's inexcusable is to inflict the rest of your team with your nonsense.
I got in a bit of a disagreement with teammates at a previous job. I liked these teammates, they were very smart and nice people, but for a specific project I wanted to use LMAX Disruptor, and the excuse for not using it was very literally “we don’t want to make people learn anything”.
That stuff blows my mind; aren’t we engineers? If we’re not willing to learn new things and adapt, what exactly are we offering that a high school kid who bought an “Intro to Java” and “Intro to Spring” book can’t?
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 actually fun to write, even for a grumpy FP advocate like me. Virtual threads make concurrency a lot simpler, and now that there’s proper records and ADTs (in the form of sealed interfaces), along with pattern matching, the language is actually pleasant to use. I haven’t dived into 25 yet, but I suspect I will like it as much or more than 21.
The biggest issue, though, is that Java programmers won’t use the new features. It was like pulling teeth at my last job to get people to use stuff from Java 8 (e.g. the `var` keyword), and none of my coworkers even knew how to use NIO or BlockingQueues which I think predate agriculture. I mean, hell, I had explain what “fairness” was to engineers when using a ReentrantLock because someone “corrected” my code with `synchronized`.
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 have met some extremely intelligent Java engineers who do have intellectual curiosity, so I am not saying it affects everyone, but I do think that they are the minority. Java 25 might add every feature to make my wildest dream come true but it won’t matter if I am not allowed to use it.