[spectralflux]

Speaking as someone who technically would fall in b) in your community list: Java has all of those nice features and tooling now of other static languages, and when I tried out Go I found it tedious to work without them, especially generics.

I mean sure, I'd rather be working in Kotlin, but Java is at least acceptable now.

[cmrdporcupine]

Yeah I am speaking as a person who was a professional Java developer for years, but the last time I worked in it was 8 years ago, and it was painful given I had experienced working with Ocaml, Erlang, and Scala. Kotlin wasn't a thing yet.

I've been working almost exclusively in C++ @ Google since then.

Java looks much improved now. But I still feel like there's a culture of complexity and bloat in Java code ... But I work in the Chromium code base and it has the same problem :-)

[spectralflux]

Old code and programmers with old ideas hold back "real life" Java projects quite a bit from what they technically could be in a more modern form.

Complexity and bloat definitely come with that, I think some folk get used to building EnterpriseTurboWidgetFactoryImpl type horrors and never consider the language doesn't need to do that kind of thing any more... Java being so backward compatible I think also means it doesn't do enough to discourage that either though, which is also a reason why Kotlin is so nice -- the lowest effort solution is miles more understandable.

[x87678r]

> I think some folk get used to building EnterpriseTurboWidgetFactoryImpl type horrors and never consider the language doesn't need to do that kind of thing any more.

Did it ever though? I feel this junk comes from the Spring side more than pure Java. I'd love to know a good way to get rid of it as Spring is everywhere.

[cmrdporcupine]

Ho man, I remember when Spring came on the scene and it was a breath of fresh air compared to the 10,000lb J2EE gorilla that was common then.

No, Java has always had ExcessivePatternFactoryImpl-itis.

And what's worse is that the language never had good supports for the patterns that the community seemed to prescribe. So you had an insistence on value and transfer objects and JavaBeans with pointless getters and setters leaking out their eyeballs, but no language support for properties or automatically managing these data objects. Or a desire to push the visitor pattern etc. but no pattern matching constructs. Apart from generics, which ended up being excessively complex and practically turing complete, the language was horribly anemic and repeatitive.

[pjmlp]

Ho man, I remember when J2EE came on the scene and it was a breath of fresh air compared to the 10,000lb CORBA and DCOM gorilla that was common then.

People like to bash Java without understanding how things turned out as they did.

[x87678r]

Ho man, actually I understood both CORBA and DCOM well it was a lot simpler than today's nightmare mish mash of everything.

[spectralflux]

I've seen a lot of that kind of thing in non-Spring code (I can think of at least one codebase where they rejected using Spring as terrible, but their hand-rolled alternative eventually grew to something much worse), and honestly good Spring Boot code looks surprisingly nice and free of that kind of thing.

Maybe it was old school Spring that started it (it seems to have seen a big uptick in enterprise grossness in the 2000s so its an interesting hypothesis), but even Spring has moved on from it.