
Everything that's wrong with Java in a single class - fpp
https://plus.google.com/105201233571140699617/posts/1QhcnQizuPc
======
cletus
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.

~~~
famousactress
In his defense, I don't think the long class name is the problem he's pointing
out.. it's the over-patterned, over-generalized nature of something that
barely does anything.

The class's description is _"Convenient proxy factory bean superclass for
proxy factory beans that create only singletons."_

Seriously? That's fucking hilarious.

~~~
haberman
My favorite part is that the first word is "convenient." At the point that you
need this class, absolutely nothing about the situation could possibly be
considered "convenient."

~~~
famousactress
Oh totally. I'm enjoying believing that this commit was part of a patch
submitted with the explanation:

 _"Added a new superclass because you wouldn't believe how hard it was to to
create beans that create beans that create only singletons!"_

Turtles all the way down.

~~~
chris_wot
Yeah, that would be amusing if it was accurate. Only that's not what it does.
It is actually a way of extending the bean creation part of the framework that
produces singleton scoped proxy objects.

I'm curious: what would _you_ name that class?

~~~
famousactress
I can assure you I wouldn't name that class.

But honestly, I'm kidding around. I'm not arguing the class is silly, or
poorly named. I bet it's perfectly named. I'm not arguing the author did a bad
thing here, I'm sure he or she did something awesome. All I'm saying is that
the context that makes writing that class description necessary is totally
hilarious.

Let's just agree on that. It doesn't mean Java sucks or Spring sucks. Big
complicated projects sometimes lead to pretty wacky situations and we ought to
be able to laugh at them. I'm certainly not suggesting other languages don't
have the same culdesacs of lunacy.. they totally all do. Can you imagine the
number of times someone's posted "Everything that's wrong with Perl in one
line of code" ?

I really don't see any reason to take this stuff so seriously.

~~~
chris_wot
The context makes it entirely appropriate. A FactoryBean allows you to
construct complex objects, or construct objects Spring can't easily create
itself (e.g. JndiFactoryBean). A ProxyFactoryBean builds Spring AOP proxy
beans.

As it turns out, there was no need for the class as it has been deprecated.
However, providing an abstract singleton scoped proxy factory bean is indeed
convenient. If there was a need for a factory that creates AOP proxies then it
would be very useful to have an abstract class that implements most of the
methods for you, and create them with singleton scope. In that case,
AbstractSingletonProxyFactoryBean is sensible.

It's a corner case. It was used by one class, but that was deprecated later,
so this was deprecated as there wasn't really a need for the convenience
class.

I take this lot of stuff seriously because I see a lot of ignorant pattern
bashing by those who haven't taken the time to understand why patterns are
very useful and potentially can make OOP code cleaner and easier to maintain.

~~~
famousactress
For the record, I spent 10-12 years coding Java (the last 4 or so w/ Spring).
Lots of OOP, lots of pattern based enterprisey big boy stuff. I definitely
have a solid (but atrophying) understanding of the concepts. I get that
they're the right way to do big Java apps. But Java makes implementing them
fucking laborious. Back when that was all I knew, it seemed elegant and I was
used to the scaffolding.. but the truth is that in a number of other languages
the same patterns require so much less scaffolding and even thought, that we
don't even notice them. They're a given.

I give my users vastly more value-per-line-of-code now than I ever did writing
Java.

That said, I have nothing against Java or folks that enjoy doing it... but
even when it was a language that I was knee deep in and stoked on, I was able
to laugh at some of the shark-jumping complexity of these cartesian products
of patterns that would arise.

~~~
chris_wot
That's sort of the point of the class in question: use it derive your own
class an you've extended the Spring framework...

------
sutro
I'm kind of partial to
com.sun.java.swing.plaf.nimbus.InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState.

A "non-haiku" has been written in its honor:

<http://stackoverflow.com/a/891589>

~~~
mahmoudimus
Hahah, I love this. Very clever!

------
dustingetz
> "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

~~~
mangler
Clojure functions are Java classes. It's not much different from using a Java
functional libs. Except that Java will probably be faster as Clojure still
doesn't do primitives and stuff (not sure about that one, may be it already
does)

You can do all the functional stuff in Java, Clojure is doing exactly that. It
will be more verbose, but once you learn the ropes it just looks different, it
is not different.

~~~
dustingetz
here is some code i wrote last week: <https://gist.github.com/3758511>

it was a method i extracted from some old code somewhere else while i fixed a
bug in it. the functional programmer in me sees opportunities to generalize
(and prevent future bugs here), so i try to refactor it into a defaultdict and
a higher order function, using guava. 20 minutes later I still don't have
working code, i revert, curse the gods because this is a 30 second refactor
even in python let alone clojure, and move on, i don't have time for this
shit.

its not about it looking different. it doesn't matter that closures and
objects are turing equivalent. its a syntax problem.writing functional java
code has too much friction and is not worth it.

this is not even getting into how any hardcore functional code needs
persistent data structures to be fast, which means a) you need to write your
code against a 3rd party collections library instead of JDK provided
implementations, and b) any interop with 3rd party code will now imply a
conversion (copy) at the boundary.

~~~
anakanemison
I agree that Java can be awkward if you're trying to write using functional
idioms.

Still, in case you were interested, I commented on your gist with a potential
solution.

------
spacemanaki
As others have pointed out, this really should be titled "Everything that's
wrong with Java _culture_ ..."

For a more technically critical look at Java the _language_ , I recently
stumbled on this video while watching a Scala talk Martin Odersky recommended
in the first few sessions of his new Coursera class...
<http://www.youtube.com/watch?v=hcY8cYfAEwU>

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)

~~~
ww520
What is the Java culture? I don't think there's anything. There are so many
Java programmers that there are bound to be bad ones along with the good ones.

~~~
spacemanaki
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...](http://michaelochurch.wordpress.com/2012/04/13/java-shop-politics/)

~~~
ww520
What is wrong with Java encouraging OO style programming? Some people will do
very well with it and some will not. Functional programming is not the holy
grail and some people are very bad at it. Do those bad functional programmers
invalidate the whole functional programming approach?

I found that the whole notion of finding some bad examples of a practice and
then offer that as a proof to invalidate the whole practice very distasteful.
The lynching mob incited from the blog post's false information just shows how
far it can go.

~~~
spacemanaki
> What is wrong with Java encouraging OO style programming?

There's nothing wrong with it, if you think OO is a good approach to
structuring programs. I happen to think it's not that great an approach. But
Java gives you no option, you can't have just "some OO" and some of something
else. I think that's a serious mistake. You're welcome to disagree.

I didn't say FP is a holy grail. However in my limited experience, OO is
definitely not either.

All that said, there's nothing wrong with constructive criticism, which is all
I've been trying to provide. I don't think I've participated in any lynch mob,
I'm sorry if you construed my light jab at "Java culture" to be offensive.

~~~
ww520
Sure. If you don't like OO and not found it to be productive, you don't have
to use it. And you are more than welcomed to state OO doesn't work for you.
However, blanket statement like Java sucks or OO fails (not directed at you)
is not constructive criticism. It's just insecure programmers using other
languages trying to justify their insecure language choice.

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

Also, many of the abstractions start as good ideas, but they soon become a
hammer and everything else becomes an
AbstractNailFactoryInterfaceManagerProxy.

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

Now if you wanted to criticize Spring and cargo-cult enterprise Java
development, I think that's reasonable.

~~~
jebblue
Good observation, I've read several posts which complain about factories and
proxies. With Grails (which can be all Java no Groovy if you want), Zk, GWT,
etc. I can do powerful web apps. No EJB and no Spring needed.

~~~
absconditus
"Powered by Spring, Grails outperforms the competition." So I guess that there
is some Spring.

~~~
jebblue
Yes but I don't recall having to do anything directly with it so the reference
is good for me. If I need logging I expect it to work not worry that some bean
config file isn't set up right. If the Grails developers found Spring helped
them, cool, as long as I don't have to deal with it.

------
Tichy
My favorite joke in that vein is

"I had a problem and thought to use Java - now I have a ProblemFactory"

~~~
dguaraglia
More likely just one implementation of IProblemFactory.

~~~
jebblue
If I wrote that it would have been downvoted to - points range by now.

~~~
dguaraglia
I'm a swell guy, that's why I don't get as much hate (?)

~~~
jebblue
My comment was about the content or lack thereof of your comment. It wasn't
personal. So do down votes indicate people hate people on Hacker News? I don't
hate anyone. Is it an attempt at humor to suggest I'm hated? If anyone hates I
feel sorry for them, I hate no one.

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

~~~
snorkel
Agree. Java coders seem to have a habit of over-solving the problem with
useless layers of abstraction. I recall trying to create a silly video editor
in Java, using a common vendor framework for media files, simply opening the
file then extracting the Nth frame involved instantiating 12 layers of
classes, like nested Russian dolls, every layer just as useless as it's parent
class. What a waste of time it was to consider Java.

~~~
ww520
So you have one bad experience with one vendor's library and you equate that
with the Java language?

------
aut0mat0n1c
Hello and welcome to 2008!

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.

~~~
hmottestad
No need to create javadoc, takes people 4 years to read it anyway :D

~~~
sukuriant
Hey now. I find Javadocs to be among the easiest to read formats of all the
different documentation styles. Right up there with Python's standard one (or
whatever tool python's default library as well as numpy and scipy use), maybe
even better.

~~~
chimeracoder
Python's is _far_ superior to Javadocs.

JavaDocs is one of the earliest (popular) standard tools for documentation, so
I'll give it that, but it suffers a number of problems - problems which are
partly relics of the Java language, but that's no excuse.

JavaDocs is too focused on documenting classes, rather than documenting
functionality (Python docs, by contrast, focus on modules, which are
themselves arbitrary chunks of code with connected functionality).

JavaDocs doesn't make the package/class hierarchy terribly clear - this is
intrinsically tied to Java's overcomplicated class hierarchy and needlessly
complicated package system, but it carries over into poor documentation as
well.

JavaDocs also doesn't have a culture of providing complete examples of code,
which exacerbates the two aforementioned problems.

That said, JavaDocs has inspired other good tools, so I'll give it some credit
for that and write these criticisms off as vestiges from a time long past.

~~~
ww520
I found Javadoc well better and more informative than Python doc. Python
module is nothing but a watered down version of a static class, so whatever
applied to a class, you can say the same thing on a module.

------
labizaboffle
No programming language that I have encountered so far is wrong. It is only
different.

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.

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.

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.

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.

~~~
jasonwatkinspdx
Cucumber has some flaws in my opinion, but I think saying its intent was to
allow non-developers to write tests is mistaken.

It's more a straightjacket that ensures a minimum of mutual intelligibility,
particularly when a developer and domain expert are collaborating. Trying to
make a tool that non developers can use to write tests is nearly pointless
(selenium remote control for example). But adopting an approach where an
analyst can look at what's on the screen and say "Hey, no, that's not right.
We have to get the foo form in the file before it goes to bar department, not
after." It's also nice in the context of CI, where non developers can look at
a status webpage and see the state of an app is without drowning in technical
details.

As an aside, my criticisms:

I hate how favors a specific BDD template (As A, In Order, Given, When, Then
etc) rather than letting people pick their own language sensible for their
project. The product/business people I've put in front of cucumber generally
disklike that language, and often feel resentful for it being forced on them.

And secondly, I think the way statements are matched to step definitions via
regex is awkward. Regexes in general tend toward frustrating abstraction. Do I
want $1 or $2 or $3 or wtf was $7 supposed to be again? They also don't
compose well. In my experience this choice ends up making the step definitions
a cluttered dumping ground that takes more effort to organize than I'd like.

I think both of these would be solved by using a more proper grammar
mechanism, probably PEGs, and keeping the rest of the tooling ignorant about
its specific definitions.

------
csense
"Convenient proxy factory bean superclass for proxy factory beans that create
only singletons."

It's concise, precise, clear functional description of the class. It's also a
profound commentary on the shortcomings of the Java ecosystem.

If you enjoyed this, recommended reading:

[http://steve-yegge.blogspot.com/2006/03/execution-in-
kingdom...](http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-
nouns.html)

------
27182818284
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?"

------
runn1ng
Can somebody smart please come and explain what this class actually _does_?

~~~
virmundi
As one of the commentors pointed out in the original post, that class is
helpful for making AOP driven applications. You could also use it in a DSL
system if you wanted. Basically with Spring there are a lot of classes, the
majority of which you will never use and should probably never use. But if you
have the need, you've got a lot of power.

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

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.

------
jmgao
The carryovers from C, and resulting insane behavior when mixed with Java's
usual syntax are pretty hilarious, too.

    
    
        public int[] what()[]
        {
            return new int[0][0];
        }

~~~
jebblue
I've been coding in Java since it came out in 1995 and I never did that,
didn't know you could or why you would want to. So what's your point? Java, C,
C++, even C# are readable by average people like me. LISP, Haskell, Ruby,
Scala, Smalltalk all look like they were written by aliens.

If you really want to see something funny look at JavaScript code which
combines integers and strings. Things that Java would complain about
immediately, JavaScript tries to actually run with unpredictable results.

~~~
jeremiep
Thats a gross comparison of languages.

Java, C++ and whatnot are imperative languages, of course the syntax is gonna
be different to declarative languages such as Haskell or Lisp. They're also
only alien at first; once you get used to a declarative syntax you never want
to write imperative code again. It would be like going back to monochrome
after experiencing color monitors.

We have some programmers at work who can't think outside the C++/Java/C# box.
They also tend to be the worst programmers even after decades of experience.

~~~
virmundi
Perhaps this isn't quiet HN quality of a comment, but I'd love to go to a grey
scale screen. I've been trying to figure out how to do that for years. Never
could. The simplicity of it would be wonderful.

In the same way, Java is noisy, I admit that, but it's fast, powerful and
fairly easy to understand when executed correctly. I'm not saying you can do
the same thing in other languages, but it's a good language for systems,
especially middle-ware/server side development. It's horrible for Web Page
development since JSPs suck and custom tags never caught on in most
development shops (they're used because the framework provided them, but even
when .tag files came out few used them to encapsulate screen behavior). But
Web Development has moved on to JS on the client and REST on the back, so
again Java is pretty good too.

~~~
jeremiep
I tried server-side development in Java, didn't like it at all. I'd pick
Haskell or Erlang over it in a heartbeat.

You can't easily build fault-tolerant distributed systems using only classes
without concepts such as function purity and data immutability. Java's type
system also happens to be neither sound nor correct; casts are everywhere and
NullPointerExceptions can fly around. You're constantly working against the
language to write safe distributed code. If Java was safe as a language, it
wouldn't require so much debugging time. Haskell was an eye opener for this.

For systems programming I now use exclusively C and D. In the end, Java is
only a viable option when you don't know any better. Most Javaland programmers
I know of also happen to be blub programmers. They don't know unix, regex,
functional style, don't write tests and the list goes on. They do, however,
know Agile and UML.

Maybe that's what I don't like about Java. It's culture killed technical
knowledge and replaced it with bureaucratic management.

------
matt2000
This is pretty funny, and yes Spring itself is pure insanity, but it's not
really fair to equate Java the language with Spring the framework.

------
benjaminwootton
And this is positively lightweight compared to J2EE which Spring superseded.

~~~
jrabone
Take a look at J2EE 6 - you might find it's Spring which is the heavyweight
these days. Although as of 3.1 at least the need to write your programs in XML
is going away...

~~~
vetler
I'd argue that the right time to start writing Java EE applications is _right
now_. With Java EE 6, JBoss AS 7 and frameworks such as Arquillian, Java EE is
a pleasure to work with.

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

You can come up with ugly names for classes in any language.

~~~
columbo
I think it speaks more to the community than the language (and arguably there
is also no such thing as a community).

After years of consulting I can't remember how many times I've walked into an
Enterprise Java Shop(TM) to find TemporalSystemLoadOrganizers,
IntransitPredeterminedApplicationUtilitySources,
MetaphysicalManipulatitiveQuantityDisorderRecognizers only to find out that at
the end of the day these abstract-factory-driven-decorated-decoupled-
dynamically-injected-frameworks tend to do such obscure/complicated things as
"Update a user's first name" or "Show the last item the user has purchased"...

Again, not Java's fault and no question you can write very fast, beautiful and
clear code in Java. I'm sure every language has specific warts and most of
them probably reside more with the community than the syntax.

~~~
bane
Right, it's not the fact that you can name things poorly in any language, it's
that non-descriptive, overly verbose word-jumble vomit is built and presented
seriously and without irony as common practice.

~~~
taf2
Either it's the people who write Java, or something intrinsic in the design of
the language itself that drives people to write code in this extremely verbose
way. I've always leaned towards the latter...

~~~
patio11
A bit of column A and a bit of column B. People who write Java are exposed to
rampant overuse of design patterns when looking at examples of a) what the
community considers Good Java and b) all over their internal projects. This is
partially because Java lives, by design, in a Kingdom of Nouns and partially
because there's just no good way in the standard language / library /
toolchain to do some things without going really pattern heavy.

For example, assume I've got a list of students, and I want to show all the
ones who haven't taken at least one exam, sorted by last name. Here's the
relevant pseudocode in Rails:

class.students.select {|student| student.tests.inject(false) {|acc, test| acc
|| (!test.taken? )}}.sort {|a,b| a.last_name <=> b.last_name}

That just flows from my keyboard as a Ruby/Rails programmer, is pretty much
instantly comprehensible to other Rails programmers, and (while others might
disagree with stylistic choices, variable names, or whether to use that weird
&syntax to do the sort) would be considered "good enough Rails code to ship."

I will take the liberty of pasting my Java implementation into a gist _-to
avoid breaking HN_ :

<https://gist.github.com/3760402>

A nice, svelte 38 line method, which will be reused via copy/paste a hundred
places in my codebase.

Incidentally, at my previous Big Freaking Enterprise job, the user need "Make
a page for a class where we can see all students who haven't..." would get
quoted to them as "No problem, that will cost you $1,000. Are we green-lit to
implement or do you want docs written first ($250)?", because the core logic
I've shown you is the tip of the iceberg of how sucky that experience is going
to be. We haven't even started with the XML files and annotations required to
hook the new actions together yet. By comparison, as a Rails developer, in
lieu of getting you to sign off on a $1,000 line-item to your next invoice I'm
inclined to show you a _totally working page_ and ask you "Is this what you
wanted?" because implementing it is easier than talking about implementing it.

~~~
hythloday
I don't want to play code golf with you, because I think your point is
generally valid, but you can happily and idiomatically reduce the Java method
itself to 10 lines with some sympathetic scaffolding from the other classes
(this is actually how a lot of code in our game is implemented rather than
some theoretical optimum):

    
    
      public class Student implements Comparable<Student> {
        @NotNull public List<Test> getTests() { ... }
        @NotNull public String getLastName() { ... }
        @Override public int compareTo(Student that) {
          return getLastName().compareTo(that.getLastName());
        }
      }
    
      List<Student> studentsWhoHaveNotTakenAtLeastOneTest() {
        TreeSet<Student> studentsMissingAtLeastOneTest = new TreeSet<Student>();
    
        for(Student student : getStudents()) {
          boolean allTestsWereTaken = true;
          for(Test test : student.getTests()) {
            allTestsWereTaken &= test.isTaken();
          }
    
          if (!allTestsWereTaken) {
            studentsMissingAtLeastOneTest.add(student);
          }
        }
    
        return new ArrayList<Student>(studentsMissingAtLeastOneTest);
      }
    

The point I'm (perhaps ineptly) making is not that Java isn't all that verbose
(because it obviously is) - rather it's that you don't get much of a stack of
abstraction by default. If you don't take the time to implement that
abstraction, you're going to have a bad time, but if you do, it's not
appalling.

~~~
rmc
that, or even 10 lines, is still several orders of magnitude more code than
how you do it in a dynamic language like ruby or python

~~~
hythloday
It's not really dynamism so much as a functional outlook. Here it is in Scala
(probably with a healthy number of syntax errors, and certainly with a whiff
of inexperience):

    
    
      def studentsWhoHaveNotTakenAtLeastOneTest = getStudents.filter{s => s.getTests.filter{t => !t.isTaken}.size > 0}.sorted
    

You could get a similar amount of code in Java using something like
FunctionalJava but that's not really a fair comparison, because patio11 is
illustrating Java as it's spotted in the wild, and thus so am I. But with
appropriate libraries and implementation patterns you can certainly write
concise Java if you so choose.

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

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

Perhaps if you ask someone to build a Java framework _WITHOUT_ using the
"private" keyword, maybe it will lead to a whole different revolution ;)

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

The issue with Spring, though, is very real. The key problem that framework
authors want to solve is giving programmers _the correct slots to place
functions in_. 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.

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.

------
moondowner
I guess that almost no one here in the comments uses Spring Framework.

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.

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

This is a prime example of what "ravioli code" looks like.

It's probably as easy to read goto spaghetti as it is to try to decipher
whatever this class does.

~~~
chris_wot
What's so hard to understand? It's a convenient superclass for FactoryBean
types that produce singleton-scoped proxy objects. If you understand the
basics of Spring and how Spring does AOP, then this isn't difficult to
understand at all.

------
winteriscomming
The class made total sense to me.

This is common stuff in enterprise software world.

------
chris_wot
This is a part of the 2.x Spring _framework_ 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 _Java_ issue, or
b. say this is even an issue with AOP IoC frameworks.

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.

------
xrt
I genuinely thought this was put together as a rather good joke until I
studied it a bit.

    
    
      Is the object managed by this factory a singleton?

------
djhworld
You'll find this all the time in enterprise software, but not elsewhere from
my experience.

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.

I suspect once Java 8 comes out stuff like this will slowly disappear from the
radar.

------
joestringer
Original source..
[http://static.springsource.org/spring/docs/2.5.x/api/org/spr...](http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html)

~~~
chris_wot
Better documentation:
[http://static.springsource.org/spring/docs/current/javadoc-a...](http://static.springsource.org/spring/docs/current/javadoc-
api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html)

------
engtech
the source page that the google+ is commenting on was on HN a while back, but
didn't get many comments

<http://news.ycombinator.com/item?id=2807908>

------
exabrial
The class in question was designed in 2005...

------
ww520
This has nothing to do with Java. It has the do with that particular project.

------
littlemerman
Does this matter?

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

------
lucian303
Well you forgot the JVM. Can't put that in a class, other than a class of its
own. Ugh.

~~~
spacemanaki
The JVM is usually heralded as one of the _good_ things about Java. What's
wrong with it?

