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:<p>- Java logging is a clusterfuck<p>- 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;<p>- No lambdas yet;<p>- Type erasure in generics and the consequences thereof (eg inability to create generics of primitive types unlike C#);<p>- Checked exceptions;<p>- No function references, lambdas, etc (still a year+ away);<p>- 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;<p>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.<p>But long class names? Really? Is that all you've got? Who cares?<p>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.<p>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.<p>The thing that really bothers me about this is the <i>tone</i>. 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.
I'm kind of partial to
com.sun.java.swing.plaf.nimbus.InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState.<p>A "non-haiku" has been written in its honor:<p><a href="http://stackoverflow.com/a/891589" rel="nofollow">http://stackoverflow.com/a/891589</a>
> "it's not java's fault" (from multiple comments)<p>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.<p>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 <i>even with a team who already understands how to think this way</i>.<p>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.<p>It's definitely java's fault, and all the best language designers know it.<p>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. <a href="http://queue.acm.org/detail.cfm?id=2038036" rel="nofollow">http://queue.acm.org/detail.cfm?id=2038036</a> - OCaml for the masses, Yaron Minsky, Jane Street
As others have pointed out, this really should be titled "Everything that's wrong with Java <i>culture</i> ..."<p>For a more technically critical look at Java the <i>language</i>, I recently stumbled on this video while watching a Scala talk Martin Odersky recommended in the first few sessions of his new Coursera class... <a href="http://www.youtube.com/watch?v=hcY8cYfAEwU" rel="nofollow">http://www.youtube.com/watch?v=hcY8cYfAEwU</a><p>It's pretty meaty, although it looks only at Java 1.0. Many of the criticisms aren't things I would have necessarily thought of first, and it gave me something to think about in terms of what my own priorities are. (For instance, the lack of first-class functions and closures gets no mention at all)
The thing is, it's not Java's fault. You can write good Java code. It can be small, and easy, and nice. The problem is the word Enterprise and the abusive abstractions that seem to come along for the ride.<p>Also, many of the abstractions start as good ideas, but they soon become a hammer and everything else becomes an AbstractNailFactoryInterfaceManagerProxy.
If anything, that's an indictment of the Spring framework, which you certainly don't need to write Java. For instance, there are over 500,000 Java apps in Google Play market, and I'm pretty confident most of them don't use Spring.<p>Now if you wanted to criticize Spring and cargo-cult enterprise Java development, I think that's reasonable.
My opinion goes like this: java is a verbose and hard-to-change language compared to ruby/python/js/etc so people think "I'm going to create this extra layer/abstraction just in case someone needs to change/use it for something else later" while dynamic language guys just solve the problem at hand and then improve it later because it's painless to do so.
Hello and welcome to 2008!<p>Seriously though, if you are going to rehash this tired schtick then at least make intelligent points about the problems with the language. I have been writing Java for over a decade and I can tell you are a number.
No programming language that I have encountered so far is wrong. It is only different.<p>What is "really wrong with Java", not the language but part of the "culture", is a tendency for writing excessive code and xml, abstraction, mocking, etc. but overdoing things happens everywhere.<p>And a ridiculous "Ruby culture" thing was a DSL used for BDD called Cucumber. It promised tests that look like English so that analysts could write the tests, but then you had to write backing code so that would work. But a lot of people still use it.<p>And a ridiculous Javascript thing is Node. Javascript on the server? You have to be fucking kidding me. But now you can get a nice job in SF with JS experience.<p>Pointing these things out is useless. I make a lot of mistakes. Many publicly and online. People grasp onto "bad ideas", but really they are just ideas later proven to be not as good as some other idea. So, write your "everything that is wrong with Java" classes, SpringSource/VMWare/EMC employees. Nothing wrong with that.
"Convenient proxy factory bean superclass for proxy factory beans that create only singletons."<p>It's concise, precise, clear functional description of the class. It's also a profound commentary on the shortcomings of the Java ecosystem.<p>If you enjoyed this, recommended reading:<p><a href="http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html" rel="nofollow">http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...</a>
Similar to the classic dig on C++,
"If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one?"
I guess I don't get what the problem is with this? It seems a fad to me that people are bashing Java, for whatever reason everybody is jumping on the bandwagon. When I look at Objective C the syntax for doing simple things like initializing variables can be incredibly verbose, but all you hear on HN is how gorgeous it is.<p>I admit it is a bit funny to see a class with so many design patterns employed. But nothing about it is difficult to understand and the name is certainly descriptive. I don't see how it can be considered over-engineered without knowing the context. This just looks like one class in a larger framework to me.
The carryovers from C, and resulting insane behavior when mixed with Java's usual syntax are pretty hilarious, too.<p><pre><code> public int[] what()[]
{
return new int[0][0];
}</code></pre>
I'm not sure how one framework developer's naming choice (a framework which by the way, needs to do some pretty meta things in regards to creating factories for other factories, and which is using the term "singleton" to mean something different than usual) is a criticism of an entire language.<p>You can come up with ugly names for classes in any language.
I have a simple question: is the root to all of this infrastructure problems (proxys, abstractions, etc.), the fact that Java introduces a fear of changing state (i.e. the existence of the "private" keyword) ? Since Java guards private variables so effectively and proselytizes a fear of state, the natural evolution of the community to build these layers.<p>Clojure is not a good comparison, since it avoids fear using immutable state.
Ruby/Python is also not a good comparison since, well, it does not respect the privacy of state in any manner. The frameworks that have naturally evolved there, reflect the philosophy of need-to-keep-things-simple (which is the only way to work in a world where state cant be abstracted out).<p>Perhaps if you ask someone to build a Java framework <i>WITHOUT</i> using the "private" keyword, maybe it will lead to a whole different revolution ;)
This is truly an issue with Spring, not with Java. An argument could be made that such a class is a symptom of some cultural problem with how Java developers tend to do things, but the OP is not making that point.<p>The issue with Spring, though, is very real. The key problem that framework authors want to solve is giving programmers <i>the correct slots to place functions in</i>. Oddly, Java is not very good at providing the kinds of slots that seem natural, particularly because of it's lack of lambdas. Plugging a function into a Java project requires that you participate in the inane Type-Name-Game whether you want to or not.<p>Play this horrible game long enough, and you will get the problematic names that the OP has discovered. And it only gets worse for in-house software.
I guess that almost no one here in the comments uses Spring Framework.<p>Maybe the name of the class is long and it's usage (and description of what it does) unclear by non-Spring developers, but know that it's a proof of great understanding of design patterns and of aspect oriented programming.
A few days ago there was a discussion about spaghetti code, and in the comments other flavors of pasta were discussed. One of them was ravioli.<p>This is a prime example of what "ravioli code" looks like.<p>It's probably as easy to read goto spaghetti as it is to try to decipher whatever this class does.
This is a part of the 2.x Spring <i>framework</i> that is used only when you need to use some fairly specific AOP functionality. Given its use is very rarely used by Spring apps I hardly think you can a. say this is a <i>Java</i> issue, or b. say this is even an issue with AOP IoC frameworks.<p>In fact, it was posted by someone who doesn't even know what it's used for. I've read the Spring 2.x manuals from cover to cover, and it's a necessary but esoteric part of the framework.
I genuinely thought this was put together as a rather good joke until I studied it a bit.<p><pre><code> Is the object managed by this factory a singleton?</code></pre>
You'll find this all the time in enterprise software, but not elsewhere from my experience.<p>This is a result of people reading their design patterns book and thinking they've mastered the world, but in reality it's just papering over the cracks of the deficiencies of Java.<p>I suspect once Java 8 comes out stuff like this will slowly disappear from the radar.
Original source.. <a href="http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html" rel="nofollow">http://static.springsource.org/spring/docs/2.5.x/api/org/spr...</a>
the source page that the google+ is commenting on was on HN a while back, but didn't get many comments<p><a href="http://news.ycombinator.com/item?id=2807908" rel="nofollow">http://news.ycombinator.com/item?id=2807908</a>