[michaelrpeskin]

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

[tombert]

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.

[javanonymous]

I think it has a lot to do with work culture. Many tend to mimic what others are doing in order to not stick out.

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 were eager to try the latest features from the start, so we never had to convince new hires.

[tombert]

That's how it kind of was in my last job [1].

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.