Everything that's wrong with Java in a single class

I hate this kind of post. It's the tech equivalent of "You're a stupidhead". If you want to criticize Java then at least make some meaningful points. Just off the top of my head:

- Java logging is a clusterfuck

- Something as simple as wanting symbolic links in a Maven build requires a third party plugin, last updated in 2007 (maven-junction-plugin) that requires something no longer in the central repo;

- No lambdas yet;

- Type erasure in generics and the consequences thereof (eg inability to create generics of primitive types unlike C#);

- Checked exceptions;

- No function references, lambdas, etc (still a year+ away);

- Eclipse is a hot mess (IMHO). And, no, for Java at least, vim/emacs simply are no better. IntelliJ is but for some reason they insist on making it hard to make plugins as their API changes every major version. Jetbrains seems to be going out of their way to make it hard;

And as far as Spring goes, it's probably long in the tooth now but people either forget or never knew just how influential Spring was in the early 2000s. Java at that time really was a hotbed for innovation (believe it or not). It may not have invented DI/IoC but it certainly popularized it.

But long class names? Really? Is that all you've got? Who cares?

EDIT: I don't care about the description either. If anything, it's probably poor text from someone who isn't a native English speaker.

As for the layering, it's nit-picking. I had a quick look and found only one use for this: CacheProxyFactoryBean. Perhaps there was more at some point? Who knows? But the subclass seems to be used in the Spring AOP stuff.

The thing that really bothers me about this is the tone. It's a bit like how among a certain set it's popular to deride PHP. In my experience, people who bother to do that (or simply enjoy it when others do) are nearly always closedminded dogmatic fools.

> "it's not java's fault" (from multiple comments)

languages have opinions. Java is designed around the principle of "everything should be a class" which makes everyone's first instinct to have lots of mutable instances with lots of mutable member variables. Turns out this leads to shitty code in the large.

Compare to Clojure, which supports mostly all the same features as Java, but emphasizes them differently. You can use mutable data, but by default everything is immutable. You can have methods and instances, but its easier to just use a function. Java can do higher order functions and closures, but they're so verbose that its better to choose imperative for/while loops over map/reduce/filter, which don't even come in the standard library. Clojure is designed to make higher order functions and expression-oriented thinking idiomatic, java makes this so difficult as to be not worth pursuing even with a team who already understands how to think this way.

Java's design leads people towards code that you're afraid to touch for fear of disturbing state somewhere else which causes failures unrelated to your change. That's why when you need to fix a bug, in Java, people will expose a hook here and there to make a minimum change that they are sure doesn't break code somewhere else. A decade of changes designed to expose little hooks to not break existing code, you end up with a AbstractSingletonProxyFactoryBean with intercepters and proxies and loaders. Nobody is claiming that AbstractSingletonProxyFactoryBean is an abstraction. It came into existence over time because it was the easiest way to fix bugs and adapt to changing requirements while not breaking existing code.

It's definitely java's fault, and all the best language designers know it.

PS Here's a paper that describes a team who migrated a bunch of excel macros to Java, found that they had built an unmaintainable mess, then took the same team and built it in OCaml, and have been using OCaml ever since. http://queue.acm.org/detail.cfm?id=2038036 - OCaml for the masses, Yaron Minsky, Jane Street

It's not the long name that's being mocked, it's the underlying problem of which the name is a symptom: that Java tends towards too many layers of abstraction, and the strict object-oriented nature means that every one of those layers is expressed as an inheritance level or a Factory object or a Proxy object, all a dozen levels away from where any action and logic is actually happening.

Objective-C looks the same to me. sorry. Rails source code also has it's pasta places. So what?

You're right, of course. Programming culture can be hard to nail down, if such a thing even exists. But would it be a stretch to argue that there is a Java community? I don't think so, and I don't think it's much more of a stretch to argue that a community will adopt trappings of culture.

Java the language certainly enforces a certain kind of programming, that Steve Yegge so succinctly identified as a "kingdom of nouns". I'm not sure if that constitutes a culture or not but it does strongly influence the kinds of programs you end up writing in Java. I've experienced some shared technical culture between companies I've worked at that used Java heavily, but of course my experience is just anecdotal.

Here's a blogpost from an HNer that argues there is such a thing as "Java shop politics" and that companies that develop certain kinds of large monolithic software written in Java and C++ tend to share something, which is not desirable. I don't really have enough experience to agree or disagree, but it's an interesting read: http://michaelochurch.wordpress.com/2012/04/13/java-shop-pol...