I also find it fun how Guy Steele had in retrospect the perfect plan for Java back in the 1990s, and it took them 15 years to come around to it:
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`.
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.
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.
import static example.Library.*;
var x = someFunction(6, ‘that’);
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)));
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'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...
This looks like a developer simply did not declare proper dependency between classes/beans.
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.
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.
Java has been trending away from this for some time now. A modern Spring app looks nothing like an old J2EE app.
----
Unnecessary opinion: I don't like either, but WebObjects sucks about 1/10th as much as J2EE.
> 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
You're absolutely right, thank you for clarifying!
https://cs.gmu.edu/~sean/stuff/java-objc.html
Hence interfaces, dynamic loading, reflection and so forth.
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.
Objective-C related content,
https://developer.apple.com/library/archive/documentation/Le...
Java variant,
https://developer.apple.com/library/archive/documentation/Le...
But, really, watch the talk. It's one of the best conference talks in computer science history.