Yes @ absurd level of abstraction, EnterpriseFizzBuzz even manages to laugh at this old-school 'Enterprise' style of writing code[1].
Some enterprises have managed to move away from this though -- DevOps in the enterprise is real and it looks pretty similar to DevOps elsewhere.
I've worked with teams in very conservative enterprises that have automated tests and CD pipelines, and release 100s of times a day, and support their own code. And with their newfound autonomy -- no more diktats about "use J2EE" from up top -- these developers did what smart developers do: simplify and reduce dependencies and tech debt. Lots of vanilla JS (or maybe React at most), plain old Java, even Kotlin and Clojure where possible (microservices made polyglot development really easy).
I've always thought this was a big reason Oracle dropped J2EE. Their most conservative customers weren't interested as J2EE had become irrelevant for their needs.
Here's a public video of how one institution (JP Morgan) managed to modernize[2].
A lot of modern Java libraries and frameworks got better, and the Java standard library itself is moving away from deep class hierarchies, but I think there's a long standing culture that dictates how Java is "ought to be written" and it's quite hard to dispel that.
A lot of this is the language's fault though. For the sake of "simplicity" Java decided to:
1. Have a bifurcated type system with boxing, so a lot of generic code had to be obtuse or use a lot of reflection (It took a long time before Java added a very flawed generics implementation and convenience functions like Strings.valueOf()).
2. Disallow standalone functions (everything has to be a method on a class).
3. Implement many standard library APIs as abstract classes (and worse - concrete non-final classes) instead of interfaces, encouraging developers to overuse inheritance where composition should suffice.
4. Not provide any mechanism for delegating to member objects.
5. Encourage the practice of getters and setters, but provide no mechanism for properties.
6. Provide neither powerful meta-programming mechanism nor a strong type system, but create a powerful reflection API instead. Any surprise it will be misused?
Nothing stopping you from doing that. For HTTP some of the newer frameworks like javalin or spark encourage it and get close to flask or Go levels of simplicity. Chose you own JSON parser, connection pool etc...
As a fan of Java I absolutely agree. Having worked with python and C codebases as well, I think every language has its own particular "degraded mess" version. A sublanguage of hacks built up over years of deadlines, inconsistent bugfixes and evolving paradigms.
One nice thing about Java (compared to C and python at least) is that you have quite a bit more tools to refactor and despegettify codebases incrementally.
All programming languages when used at enterprise level suffer the same fate, I have enjoyed Enterprise C, C++, Clipper, .NET, Java, JavaScript, bash, zsh...
