Hacker News Reader

Comment by spectralflux | Hacker News Reader

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.

View on HN

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

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.

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.

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.

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

CORBA was mostly a year or two before my time, but it wasn't terrible. Just verbose and failed by the tooling and language support at the time.

Personally I don't know how we ended up back at "RPC good" land after going through "REST good, RPC bad" for 5-10 years.

Reply on news.ycombinator.com