> I would say Java the language is fine,

When I was using it I didn't particularly mind it except for the clumsy handling of functions (i.e. as objects instead of first-class citizens) and verbosity (no automatic accessors, implicit typing, etc). Adding Lombok solved most of these. *EDIT: Except for runtime type erasure of generics which caused (not sure about new Java) performance issues and made certain type operations difficult.

> but the culture around it is what's grown the distaste many have for it.

Having to debug esoteric issues with classpath, Spring, CDI, JPA, Aspect4j, etc. is hell on earth. I've lived that life and have no desire to do so again. Because Java is the lingua franca of enterprise development it also tends to rear its ugly head on modernization projects and rewrites. 80% of the abhorrently-engineered codebases I've encountered in my career were written in Java by body shops (C# and Coldfusion were the runners up).

> The overuse of design patterns, etc.

I'm not an adherent of the design pattern cargo cult but I'm one of four people under the age of 50 that have actually read the GoF book and I do indeed sometimes name objects after patterns described in the book; I typically design components and name them such after the fact as opposed to constructing systems from the ground up using design patterns. Calling a thing that persists comments in a database `CommentRepository` is a lot more useful than calling it `CommentHelper`.

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

If Common LISP had become popular I think there would be a popular distaste for everything about it and people would be wishing they could write code in PHP, Visual Basic, COBOL, Cold Fusion, etc. (There was a popular distaste for Common LISP at the time, it was hard to find a LISPer in the 1980s who liked it. Half of that was it was hard to fit it into a 16-bit machine and wouldn't become really implementable on microcomputers until a 32-bit OS was available... Thus BASIC got another decade of life extension.)

Until Java came around every book on Object Oriented programming (say "C++") had examples such as "Stack", "Queue", etc. In the case of Java you saw people starting to write objects mirroring the business and application domains. People who were trying to use objects in Smalltalk or C++ in 1990 just weren't accomplishing enough that somebody could step back and say "object orientation sucks", rather they were getting stuck and blaming themselves or blaming the tools, rather than the concept.

I see this repeated all the time.

What people fail to realize is that the enterprise culture is language agnostic.

Before Java we were doing the same with C, C++, VB, Delphi, Smalltalk and whatever 4GLs one wants to dive into.

When Java gets replaced by TechX, the space ship enterprise architects will keep doing what they know best in TechX.

> The overuse of design patterns, etc.

Java has been trending away from this for some time now. A modern Spring app looks nothing like an old J2EE app.

A lot of us jumped off the Java train in disgust at the height of the J2EE craze and never looked back, so fairly or unfairly we'll forever be judging everything Java by that tainted memory.

A framework originally designed for Objective-C, actually.

Wait, is that true? I know WebObjects was designed around ObjC, but a quick ten seconds on Wikipedia doesn't indicate that J2EE was designed around ObjC initially.

----

Unnecessary opinion: I don't like either, but WebObjects sucks about 1/10th as much as J2EE.

You should have spent more than ten seconds.

> By the time DOE, now known as NEO, was released in 1995, Sun had already moved on to Java as their next big thing. Java was now the GUI of choice for client-side applications, and Sun's OpenStep plans were quietly dropped (see Lighthouse Design). NEO was re-positioned as a Java system with the introduction of the "Joe" framework, but it saw little use. Components of NEO and Joe were eventually subsumed into Enterprise JavaBeans.

Taken from https://en.wikipedia.org/wiki/Distributed_Objects_Everywhere

Ah, I was just quickly reading on the J2EE wikipedia entry and didn't see "Objective" anywhere on there.

You're absolutely right, thank you for clarifying!

No issues, and here is another one, while Java might have a C++ like syntax to make it more appealing to mainstream, its main influence was Objective-C, not C++.

https://cs.gmu.edu/~sean/stuff/java-objc.html

Hence interfaces, dynamic loading, reflection and so forth.

Interesting.

Bringing it back to a previous point I made, I met someone who claimed to have helped port over the WebObjects framework from Objective-C to Java, and he claimed that while it's not a 1-to-1, you can fairly easily map a lot of the Objective-C semantics to Java, making the porting process not that hard.

Yes, they are quite close.

Objective-C related content,

https://developer.apple.com/library/archive/documentation/Le...

Java variant,

https://developer.apple.com/library/archive/documentation/Le...

Yep spring since 1.12 here.

Modern Spring Boot is still incredibly bloated and full of questionable design patterns. A simple web application should not consume hundreds of megabytes of RAM by default and startup time on modern hardware should be basically instantaneous. Classpath scanning and annotations are still massively overused and most of the time they're accomplishing little more than obfuscation and turning compile time errors into runtime errors.

Why exactly? How often do you start up a web application? And it’s not like the RAM is not there to use it — thread pools, db connection pools, etc have to be set up.

Since that's an hour-long video, what do you consider the most salient points of his plan for Java that it ended up embodying eventually?

About user-grown features. Over time, Java let users expose more lower level details to the language than before.

But, really, watch the talk. It's one of the best conference talks in computer science history.

Just like any other language, in order to use Java well you have to ignore a lot of the hyped up techniques.

Overuse of design patterns seems like decades ago.

Sadly it is not: they still get taught, and then juniors come and they expert-beginner projects to death. And yes in 2022 expert-beginner is a verb! Cheers

it is painful watching this video . presentation software and projectors are truly blessing