Hacker News new | comments | show | ask | jobs | submit login

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.

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.

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

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.

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?

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.

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.

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.

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

If you spent your life being inconvenienced by the things you made earlier to make your life convenient, you'll go to extraordinary lengths to make other things that seem to make your life convenient given all the inconveniences you've already created for yourself. It does not really compute that this is another inconvenience you're building for yourself that is going to need another convenient AOP driven bean thing that you will write in a few months to get around the nonsense you burdened yourself with in the first place. It also does not help that everyone (well, at least the people with the money) is buying it and forcing it down their developers throats. If they don't want it, there's always a bunch of guys who are cheaper and will take it....

I read that as sarcasm by the author. I refuse to believe anyone would word it like this without sarcasm.

...or it could be a common malady amongst programmer: inability to write clear documentation. I note that it's much clearer in the most recent documentation.

Given that Spring is mostly used via annotations or config files, yes this is indeed useful. It helps to know what you are criticising before you show your ignorance.

A factory bean is a class that creates factories. You'll almost never need to create your own as you normally use the ones Spring provide for you. And with annotations, you'll likely never even notice them.

A proxy factory bean is used for Aspect Oriented Programming in the Spring framework. AOP is a fantastic way of doing OOP. Try reading up on it before you knock it. Spring uses AOP via proxies. By using proxies, you don't need to inject bytecode via CGLIB, which while a totally valid way of doing AOP, adds another dependency to your project which you may not want or even need.

Singletons are used by default by Spring, which is an IoC (Inversion Of Control) container. An IoC container is extremely useful as it fully decouples classes from one another - the container handles the coupling and you merely set things such as object creation up via annotations or configuration. One of the considerations needed to be taken into account when using Spring for object creation is to decide whether each object is created once and once only by the factory bean, or if multiple instances should be created. You usually use a singleton bean in Spring - otherwise you have to introduce tighter bean coupling with other beans, which kind of defeats the purpose of an IoC container.

A bean is a JavaBean, which is a very simple but powerful convention used to allow reusable components in Java.

So what does this do? It's a convenience class used to extend the Spring AOP framework should you need to do so without having to make changes within the Spring framework itself. Almost no application programmers will need to use it. However, if you have a very particular requirement for AOP proxy bean creation that is not currently handled by the Spring framework (unlikely) then you will indeed find it useful, and I dare say it is, indeed, convenient.

In short, ignorance is OK. But mocking something in ignorance is pretty foolish, and your foolishness is on full display here.

P.S. incidentally, Spring is now well past v2.5 and in fact the current version is 3.1.x. It helps to read the most up to date documentation when trying to understand something in a framework. The description of the class in the latest documentation now reads:

  Convenient superclass for FactoryBean types that produce singleton-scoped 
  proxy objects

Stop it! You're killing me! I can't breathe!

Frameworks are not applications. By their nature they are more abstract. Don't judge the code as if it was something it's not.

Totally. I've worked on some frameworks, and I get that things get hairy supporting some really crazy general and re-useable concepts. I'm not even saying Spring is shitty, or Java is shitty or anything. I don't really care... but don't you dare tell me that class isn't hilarious, because it is.

I don't really care... but don't you dare tell me that class isn't hilarious, because it is.

I don't see anything hilarious about it.

Indeed, the class isn't hilarious. Perhaps the class name initially boggles the mind, but when you learn what it does not only does it make sense, but you probably would be hard pressed to find a better name!

It reminds me: "Why I Hate Frameworks" http://discuss.joelonsoftware.com/default.asp?joel.3.219431

Hah. I'm not saying Spring is a good framework, I don't know it that well. But try building an app without any framework at all. Getting frameworks right is hard - they need to be abstract enough to be flexible, but not so abstract that you end up with a "general-purpose tool-building factory factory factory" when you want the framework to give you a hammer.

Yeah, but that's just an over-patterned object-oriented design. This has nothing to do with Java specifically.

Hardly. Firstly, AOP is a very effective and useful programming technique. It's used in a lot of places, and without it OOP would be considerably harder than it necessarily needs to be.

Secondly, this is a class used to extend the Spring framework unobtrusively if it is needed. Most likely you would never need it (if you are even someone who uses Spring, which I somewhat doubt... If you are then you should really learn more about the framework you use) but there are doubtless folks who may need it at some point for some super complex or out of the ordinary project you haven't even dreamed of yet.

well, but all java coders are this way. I'm working on a rails app built by java coders learning rails and it's, sadly, a pain in the ass, it's not that the code is malfunctioning, just that everything looks like it's a quantic mechanics equations when in reality it's just a 10 piece lego. Sure, they're not 100% is this way, but empirically I can state that, I too thought overengineering was beautiful when I was learning it, lame.

Seriously? That's fucking hilarious.

Only if you isolate it from all context. Within the context of how Spring is built and works, it's all perfectly reasonable. As cletus said above, if someone is going to slag Java, they should really pick something to pick on that is actually deserving.

And that has absolutely nothing to do with Java. Why is it Javas fault that some idiot decided to create such a class?

I guess there's a rule in place that hides the down arrow for comments in reply to my own or something. Anyways. I'd downvote if I could. The guy is almost certainly not an idiot. That's a rude, shitty thing to say.

Further, if you accept that Spring is a good idea (which in my opinion is equivalent to accepting that Java has major shortcomings that require something like Spring to overcome) then this class is likely plenty reasonable. Like other commenters have pointed out, frameworks are hard. Java makes them harder. In the context where Spring and Java are givens, I'm sure the author of the above is a very handy chap to know.

Be nicer.

[Edit: To be clear. I want to make sure there's no confusion that the point of my original comment was that the class is hilarious. Not that it's not justified, or that the author is foolish, or that Java is awful, or that Spring is awful. I don't have very strong opinions about any of those things.. other than assuming a committer on such a huge, demonstrably successful project is plenty smart and did the poor chaps who are in the unfortunate position of needing this class a great service.]

I've used Java for 10 years. I've never used Spring. I've never created an AbstractFactorySingleton. I've never used XML. There's nothing in Java that says you have to use anything in particular, apart from the runtime (Extremely solid), and the basic language syntax (IMHO nice enough).

OK, maybe they're not an idiot. Maybe it's warranted. I'd say it's probably over engineered stupidity though.

Even so, the title is like pointing to a stupidly constructed house and calling it "Everything that is wrong with bricks".

If you don't know what it's used for, or the purpose it was written for, then you aren't in a position to judge if it's stupid or not. I can assure you, it has a purpose, and that purpose is not stupid. The fact that the reason for the class is somewhat obscure and somewhat of a corner case does not make it unnecessary.

The class combines no less than 6 concepts / design patterns:

  - Abstract
  - Singleton
  - Proxy
  - Factory
  - Bean
  - Interceptors
It's not just a long name. The class makes sense in the context of this framework. The core problem (as others here point out) is that the Java flavor of OOP makes writing this sort of code idiomatic.

On the upside, you feel really smart once you grok all these concepts simultaneously. After a couple years this you get to brand yourself a "Java Architect".

Agreed, this class is an exception of excellent engineering. Maybe people who don't develop in Spring find it 'wrong', but it's not.

Overengineering at it's best.

Until, of course, you find you need to use it. Of course, you'll probably never need to use it, nor will you ever see it being used in your particular situation. But hey, it's all over-engineered nonsense, right?

This is a great comment. This is what a Java "Engineer" or "Architect" is supposed to understand. It is complex, but seems too abstracted from programming reality that it makes programming simple things more complicated then they have to be.

All of these things are useful and valid techniques for building scalable, maintainable and extensible code.

Abstract is a pretty basic OO concept. You make an abstract class when you want it to be derived and never used directly.

Singleton is where a class can only ever create one object. Harder than it sounds.

Proxy is where the class interfaces with something else. Again, very useful. Proxies are used by Spring to implement AOP.

Factory - abstracts away the creation of objects, in other words the client object does not need to know how to create objects. It's used extensively in the Spring IoC container.

Beans are object that use simple but powerful conventions of creating reusable components in Java.

Interceptors at used by AOP.

If you use these concepts as they are intended to be used then your code will be cleaner, maintainable and a joy to work with.

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.

What does that have anything to do with Java? It's the framework's problem.

Way, way, way too narrow. The Java standard library design and "framework meta-pattern" is what's being mocked here. It's java-the-community that we are laughing at via the straightforward label "Java". The fact that java-the-syntax or java-the-runtime can be used to code or deploy good software isn't really the point.

Then it would have been more accurate to refer to the standard library. There is no such ridiculous class there as far as I know.

Really? Obviously no single class is that ridiculous (hence the title of the linked article). But that nonsense is pervasive in Java, and largely driven by the standard libraries (less so the core stuff as the more peripheral layers). I specifically remembering Swing being introduced with all the MFC goodness and noticing that they'd defined and implemented a "Model" class to track state for ... a button.

You won't find anywhere near this level of abstraction in the standard library, at least not that I am aware. The Java culture is understandably implicated by this though, because Spring is not some niche framework being perpetrated in some fringe corner of the Java-verse. It is very much the mainstream of Enterprise Java. Of course there are lots of Java developers outside of that set who are doing great work. And a lot of Spring makes sense, or at least it did 8 years ago when I last looked it. This class does seem to reference a sort of endless abstraction maze that resonates with people though.

Last I checked, the standard library wasn't trying to implement an IoC container. Your comment is actually fairly amusing, given that Spring was developed originally as an answer to the overly abstract mess that was the original version of Enterprise JavaBeans.

Interestingly, things like @Inject came after Spring, and were inspired by Spring and a number of other containers.

I was just referring to the standard library in J2SE. Of course it isn't trying to do an IoC container - but there was a comment above about whether or not this is a "Java" issue and it really is not. My last contact with this was before EJB 3 so I wouldn't even try to speak to how Spring and J2EE have evolved to help manage complexity.

I found it troubling for someone to equate one class or a few classes to the whole library, the whole language, or the whole community. Those pervasive nonsense you claimed in Java have certainly work very well and been used to build many systems.

I found the Java standard library to be very good. Why do you have to mock something if you don't agree to it? There's a reason to design and build things certain way. If you don't like it, don't use it. You are not the intended audience. What is this imaginative Java community that you are laughing?

Could it be all these mocking are symptom of your insecure language choice or library choice?

The title should have been "Everything that is wrong with Spring ... ". Then it would not have been especially accurate, but more accurate. I like Java better than I like Spring. Spring made a framework out of an idea, but not all ideas should be packaged. Ideas can also be embraced. Dependency injection is an idea that should be embraced, but not as a packaged solution. It is a pattern, not a a software project.

It is a pattern, not a a software project.

So you'd rather see every project that wants to use DI, roll their own DI implementation?

Actually, it would then have been entitled "A class that extends the Spring AOP easily and unobtrusively", or probably just as accurately "everything that is right with Spring".

I seriously don't think you understand that at the core of Spring is an IoC container - it just so happens that Spring does a lot of other useful things.

I actually really like Java logging (well, I like SLF4J and logback).

On Ruby, I'm constantly at a loss on how to do logging. Sure, in Rails there's the Rails logger available pretty much everywhere. But if I'm writing a reusable library, I can't count on that. So what do I do? Demand every user of my library configure it with a logger?

The stdlib Ruby logger also has no way to fine-tune log levels by class. In a Rails app, sometimes I want debug level, but I rarely care to see each and every SQL statement. (There tend to be hacks to monkey patch around the common cases suggesting others have been similarly frustrated.) Even if I use log4r or some other logger with more fine-grained tuning, within Rails, everything will be using the same logger object, so the typical Java method of tuning by giving each class its own logger doesn't work.

Bleh. Give me SLF4J with logback any day. When writing a reusable Java library, I really have no qualms about using SLF4J.

> Java logging is a clusterfuck

Care to explain? Logback is easy to configure and extremely efficient

> 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;

If you are still using Maven it's your problem. Switch to Gradle and your life will be much better.

> No lambdas yet;

True, but if you really need them use Groovy or Scala. Groovy 2.0 is almost as fast as Java and Scala is fun.

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

True, but doesn't this lack of feature harm framework developers mostly? The same people which the article is critiquing.

> Checked exceptions;

You can just ignore them when you write new code. If you have to deal with code that throws them, just deal with them. Most of the modern frameworks nowadays don't use them.

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

Groovy, Scala and the favorite kid on the block, Clojure

> 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;

This is the only point for which I tend to agree. Eclipse is difficult to work with. IntelliJ on the other hand is a valid alternative. These days I mostly code in Sublime Text 2 though.

> Care to explain? Logback is easy to configure and extremely efficient

Logback != "java logging". "Java logging" is some messy combination of JDK logging, Logback, Log4j, Commons Logging, SLF4J, some cruft that fell out of Avalon or Fortress or whatever it was, etc. And then you try to use a library that uses Commons logging alongside another library that uses log4j directly, alongside your code, which really wants to use SLF4J... or you deploy your code, which uses log4j, into JBoss, which configures it's own hacked version of logj4 before your code loads, and you run into needing to figure out RepositorySelectors...

You'd be better off reading from Ludvig Prinn's De Vermis Mysteriis, Friedrich von Junzt's Unaussprechlichen Kulten and the Necronomicon. Ia! Ia! Cthulhu fhtagn! Ph'nglui Mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn!

>> No lambdas yet;

> True, but if you really need them use Groovy or Scala. Groovy 2.0 is almost as fast as Java and Scala is fun.

> Groovy, Scala and the favorite kid on the block, Clojure

Java's upcoming lambdas will have lazily-evaluated results from its map, filter, reduce, etc lambdas. Both Scala and Clojure already have their lambdas/functions return lazily-evaluated results, but certainly not Groovy, neither version 1.x nor the just-released version 2.0.4. Groovy's closures only return strictly-evaluated results.

In fact, 2.0.4 was released only 2 weeks after 2.0.2 to fix "some important issues with generics with the stub generator, as well as several related to the static type checking and static compilation features". (Version 2.0.3 was skipped because "it was mistakenly built with JDK 6 instead of JDK 7".) It may be "almost as fast as Java and Scala" but it certainly isn't fun or production-ready.

I totally agree on java logging. Lambdas would be nice. Checked exceptions? I love them.

Lastly Eclipse is THE best thing since sliced bread. I LOL'ed when you mentioned vim/emacs in the same sentence. Have you actually used Eclipse on a big code base? It's introspection is such a productivity booster. I've not used jetbrains in a decade, but nothing else out there beats it, hands down. Both in terms of speed and quality.

Did you read what I said? "vim/emacs are [for Java] no better". This was in part to head off the predictable chimes from some of "all IDEs are stupid, (vim|emacs) is the best thing since sliced bread".

My tool of choice for Java is however IntelliJ, which is simply light years ahead of Eclipse (IMHO).

> My tool of choice for Java is however IntelliJ, which is simply light years ahead of Eclipse (IMHO).

I agree.

Eclipse seems to always become unstable once enough plugins are installed. After a few updates and removals it ends up tipping over regularly. I suspect the underlying OSGi plugin system is a tricky thing to get right.

Intellij IDEA seems to "just work".

That said, I prefer coding in Clojure with Aquamacs but I've yet to get Clojure into a production system.

I m using IntelliJ at home but at work we use yoxos.

Yoxos allows the creation of eclipse profile that make it easier to have stable eclipse.

If you have a lot of eclipse users, I think yoxos is the way to go.

But I still use IntelliJ at home :)

NB: I m talking about this yoxos: https://yoxos.eclipsesource.com/

Yes, I read it and still think it's laughable that anyone would mention them in the same sentence...

If you haven't used IntelliJ in a decade, how can you be so convinced that Eclipse beats it "hands down"? While they offer many of the same capabilities, most people I know who have used both extensively tend to prefer IntelliJ for Java development.

I think he meant "nothing except possibly IDEA beats Eclipse". Now, whether you agree with that or not is a different story...

IntelliJ FTW!

It fascinates me that I also believe that Java has serious issues, but I differ on dimensions.

Well yes, logging. There is slf4j though. I think that works, although the fact that one needs a metaframework is... interesting.

Eclipse? I love eclipse. I used emacs every day for 2 years, IRC in emacs, news in emacs, EVERYTHING in emacs. Eventually I got sick of IMAP blocking and interrupting the world. I grew to love Eclipse because I realised I could not efficiently comprehend Java code any more without it.

Over-layering is a serious, serious problem in Java. I think I understand your point of view, but a big part of my job is performing code reviews. It really sh%ts me every time to have to jump through the Service, the ServiceImpl, then the Repository, the RepositoryImpl, the Dao, the DaoImpl and... oh, there's the fricking query. Thanks guys.

My huge problem in Java is that I always find 8 classes where 2 would do. The extra classes do serve a purpose; they fulfil stereotyped, expected roles. In some ways the boilerplace reduces cognitive overhead. In other ways, it really does not.

Personally as someone who reviews multi-million line codebases regularly for a living, I am actually terrified of hordes of new Java developers discovering lambdas or acquiring advanced generics. These things are tactical nuclear weapons of source code obfuscation in the hands of people whose judgement (through bitter experience) I no longer really trust.

Spring is not evil, but it does make life difficult because it's hard to follow references. Fortunately, whenever you see an interface Foo you normally just have to jump to FooImpl. Because it turns out that 90% of interfaces are actually not needed; except culturally, stylistically or dogmatically. Personally I think they're over-used, but that's because my observation is that most interfaces (seriously, 90% level) are implemented only once.

Agree on the checked exceptions though. That was a mistake.

I think actually there is nothing wrong with Java as a language, but without sane leadership the corporate culture of it becomes uniquely byzantine.

Regardless of this post (which, indeed, has little to do with Java per-se), Java the language might be outdated for many applications. But I believe it's now pretty widely acknowledged that Java's contribution isn't the language, but the platform. The JVM is the best performing, most stable managed runtime in existence. Not to mention the invaluable runtime profiling an monitoring that is years ahead of anything else out there. The platform (possibly used with some other JVM language) still gives the most bang-for-the-buck for performance critical, scalable applications.

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

Is that the only thing you think is wrong?

Just out of curiosity, why do you think checked exceptions are bad?

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact