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.