> Having to debug esoteric issues with classpath, Spring, CDI, JPA, Aspect4j, etc. is hell on earth.

The term "DLL Hell" came from Windows development before it. The Node/Ruby/Python equivalent is getting native libraries to build (node-gyp, I'm looking at you!). I've burned days in Ruby Version Hell and Node Version Hell. Javascript dependency upgrades are a nightmare compared to Java dependency upgrades.

I don't think this problem has gone away, or even improved. It's just a grim fact of life, and Java doesn't deserve special mention.

Despite my love for the language (and Stack has mostly fixed this), I feel like Haskell's "Cabal Hell" is amongst my least-favorite headaches from my past.

Getting weird, hard to follow conflicts between different packages on Hackage and dealing with weird compiler hack flags is something that never got fun or easy.

The things you mention are no fun either (`node-gyp` in particular), but the Java issues I encountered were far beyond run-of-the-mill runtime linking and interop issues you describe. The details are lost to time and a bit fuzzy but I recall the primary issue being competing CDI implementations stepping on each other when we tried to use JSF with a recent version of Spring... and because most everything in the Java ecosystem was doing some opaque Aspect4J magic it was nigh-impossible to debug.

If you don’t like putting objects and classes on the left you can write

   import static example.Library.*;

And proceed to write in your main method

   var x = someFunction(6, ‘that’);

in a style like C, LISP, or ML. You can write a whole program (like the answer for a HackerRank problem) in a single file. The developers of Java have always respected the ML family and JDK17 incorporates pattern matching, records, algebraic types and and many other features that make functional programming fun.

The type erasure problem for generic classes goes away when you use generic methods; type inference works without limitation for generic methods and is great for defining APIs for internal domain-specific languages

   any(grammar,you.want(ifIt.parses(ON_THE_LEFT)));

the great thing about Java is a quality IDE is certain to support this programming style.

Any complaint that the internal DSL is too verbose can be attacked by the use of code generation which is straightforward to incorporate in a maven build and your IDE. (The LISPer is using code generation and you have to do it if you want to keep up.)

I think the real majority of hate that I've seen for design patterns are when juniors go into a system looking to slap a design pattern anywhere they possibly can, quickly creating a ball of mud that is difficult to work with and figure out. At least that's been my experience (and I have to sadly admit I did the same when I was a junior without a mentor to help me through figuring out how to refactor my code into these patterns only when needed).

I'm under 50 and read the GoF book ;)

I'm one of the rare people who was writing vb and then c# during the terrible Java j2ee days. Then I got a job in a startup using Java which avoid the 'enterprise' idioms. So my experiences with Java over the last decade or so have been mostly good (except for a foray into Hibernate, never again - jOOQ for life). No crazy class models, no xml configuration, etc...

Amen to esoteric Spring issues. I once dealt with a jar that suddenly started failing despite no code changes because Spring uses the order of files in the zip file/jar to determine initialization order. Turns out one that particular time files ended up in a weird order inside the jar file.

It's natural to read and initialize the classes as they come, _unless the code defines a specific dependency order_.

This looks like a developer simply did not declare proper dependency between classes/beans.

Try doing the same with CORBA and DCOM.