Your experience doesn't nullify mine, and vice versa. There's a huge pile of legacy Java applications out there still needing maintenance and occasional new features.

You cannot judge a language and platform merely by legacy software. By that token, almost everything today is horribly broken, even trendier technologies like NodeJS or Go. You'd have to judge C by K&R standards, and C++ as the horrible preprocessor it initially was. It makes no sense!

You must judge Java by the developments of the last decade at the very least. Otherwise you're ignoring the practitioners.

Java hasn't used XML in ages and you cannot fault it for legacy apps. You could similarly complain about the horror of EJBs -- sure, but the industry has moved on and acknowledged they were a mistake.

> You must judge Java by the developments of the last decade at the very least. Otherwise you're ignoring the practitioners.

I think plurality of situations it's actually used for currently would be a better standard than what you're advocating for.

This has the advantage that the merits people judge things on, and the experience they will most likely have using it will line up.

The downside is that, the merits used may differ a bit between markets or industries, but I'm personally ok with that.

The problem with judging a language by how it was a decade ago is that you're going to be left claiming absurd, outdated things. Imagine if I claimed I didn't like Java because it lacks generics, or because it lacks lambdas, or because I really, really dislike working with EJBs, or because working with Java means "working with a lot of XML" (this would flunk you in an interview, by the way).

Imagine if I complained about Linux and all I used as an argument was the Unix Haters Handbook.

Imagine if I complained about Windows and the most recent version I had used was Windows 95.

That depends on what you want from the judgement doesn't it?

If you want to be able to know the theoretical things you could do with the language, I think your definition is right.

If you want to know the most likely experience you would have using the language, I think mine is right.

I think it also depends on what circumstances you're using the language. Spinning up a new project probably lends itself more towards your definition. If you're looking to join an existing project, mine is probably more useful.

I am judging a technology by its amount of foot guns. That's why I am more fan of languages with only one way of doing things (and even that gets increasingly rare).

Java is a pretty solid tech and the JVM is one of the best runtimes in the world. But it does offer you infinite possibilities to write awful code and that made me less interested in it with time.

I don't disagree with you there are better languages which have learned from Java's mistakes, and I don't think I've argued it's the best one. Just that it's extremely successful, a good platform, and that programming in Java doesn't have anything to do with flinging XMLs like someone claimed.

That doesn't make Java a bad choice for building new things

Agreed, it doesn't at all.

I am saying that when I was contracting with Java some years ago it was a complete crapshoot: you could get an almost brand new project with a lot of thought put in that made it a pleasure to work on, or you could get an ancient EJB mastodon that made you want to slit your wrists.

And that gamble still exists if you want to contract with Java. A lot of preliminary negotiations have to be done in order not to find yourself in a situation where you should have charged $30k a month due to the insane amount of digging you have to do just to make the thing accept one new feature.

That gamble exists in one way or the other with any tech platform. I double dare you to take on a codebase written with NodeJS, Golang or Python without checking its sanity first. This isn't exclusive to Java.