Looking at the API alone Spring feels like reading a parody on Java enterprise software written by Steve Yegge.
AbstractBeanFactoryBasedTargetSourceCreator ContextSingletonBeanFactoryLocator AspectJAdviceParameterNameDiscoverer UserRoleAuthorizationInterceptor TransactionAwarePersistenceManagerFactoryProxy SQLStateSQLExceptionTranslator SimpleBeanFactoryAwareAspectInstanceFactory ...
Legend! Nonstop administrative debris as dadaist poetry. Écriture automatique of the programming office manager or his parrot. This goes on and on for miles and miles – I count `1943` Spring 2.5 API classes+interfaces. This way it tops JEE 6 ( Glassfish 3 ) by about 450 – JEE 6 is basically free of this notational nonsense.
Spring causes a Biggus Dickus effect on me in the role of one of Pilatus guarding soldiers. It lives beyond a tolerable threshold of “software engineering best practices” not becoming comical.
for want of a nail, a programmer got lost down in the AbstractAspectOrientedSimpleBeanAdministrationInstantiationFinderSetupFactory. i start swearing on much terser APIs already. you do get the feeling this is not the way to go.
Yes, right. It is an abomination and although a rejection of a technology on aesthetic grounds isn’t the most rational decision I’ve ever made it is the one that leaves me in a healthy state of mind.
Spring lives in parallel universe which is just too far off. It is extreme even for Java proportions – more Java than Java. Compared to the ultra-orthodoxy of Spring the JEE5 standard looks like a liberal heresy. On the danger of being called a wimp, pansy, sissy etc. I’ll stick to JEE for my Jython/Jynx excursions.
Spring is nothing more than a infuckingcredibly moronic XML interpreter designed by educated morons for proud morons.
Fuck the fucking fuckers.
I thought that my personal favourite ‘AbstractTransactionalDataSourceSpringContextTests’ was long … obviously not!
I used to use Spring; but switched to Seam 3 years ago. I found that all the reasons for adopting Spring (Mainly EJB was a pain in the ass) were overcome by EJB3 and Seam.
A project that had taken me 6 weeks in Struts, took me only 3 weeks in Spring and 3 days in Seam. And yes it was the same exact project. It is one I use to learn new frameworks because I have the use cases and dom memorized.
I’m writing a GWT app. After looking at a ton of JAspectOrientedModularOverEngineeredBloatedCrap I wrote the server side of my app using simple JDBC calls wrapped in a simple (no, trivial) MVC style architecture. Easy, fast, simple. I’m obviously not cut out for the enterprise, and I’m sure it’s not agile.
Just to avoid misunderstandings. When people tell me they are productive with Spring I have no reason to doubt them. Much of the structural complexity of the framework might be hidden to them – and they use it indeed mostly as an XML interpreter for gluing components.
My main incentive is to experiment with dynamic Java compilation techniques: creating classes on the fly, creating even components/jars on the fly etc. and start within a JVM scripting language context ( I use Jython 2.5 ). It is a bit like doing research but in a “hackers way” i.e. I try to figure out if certain approaches to solving problems are possible in the Java enterprise domain and even make sense. If I can help programmers to get more control over complex enterprise systems written in Java and avoid ceremonial style programming I feel the work is justified.
Right now I can just report I got stuck with Spring which is extensible in all but the directions I want. Maybe EJB will turn out to be an easier target but I’m very sceptical that the 10 steps needed to create a HelloWorld EJB application can be reduced to one or two – I expect a failure rather than a success.
Wow, this is spectacularly short-sighted and ill-informed.
A couple of points:
Spring is a highly extensible general purpose library, with a vast array of small, specialised classes, providing entry points for either direct usage or straightforward extension at multiple levels. To that end, having clear, well-constructed and unambiguous classnames is far more important than it is in, say, a pet throwaway scripting project.
Also, given the wide range of applicability of Spring, clear naming is vital to prevent name clash both within the library itself, and within a context it might be used. Packages are all well and good, but it’s a royal pain having to use a FQN just because some library has created a class called something ambiguous like FileManager that clashes with your own hierarchy.
I’d like to know what else you’d call the TransactionAwarePersistenceManagerFactoryProxy that distinguishes it from all the other similar classes in an unambiguous way?
Dave, I’ll write a follow up and you might contribute to the little programming challenge I prepare which is just easy to solve for people who have spectacularly better Spring API reading skills than me.
Dave:
“I’d like to know what else you’d call the TransactionAwarePersistenceManagerFactoryProxy that distinguishes it from all the other similar classes in an unambiguous way?”
This is the epitome of the heavyweight vs. lightweight debate in a single question. You are asking what else to call it, others are asking whether you need it. Another way to put it: You are debating whether Spring is Done Right, others are asking whether Spring is the Right Thing To Do.
Kay:
With pleasure! I’m more than happy to eat my own dogfood publicly, and suffer the embarrassment if it all goes horribly wrong 😀
Reg:
I don’t know that it is. The TransactionAwarePersistenceManagerFactoryProxy (phew!) is a very lightweight, specialized class. It has a single purpose, expressed succinctly (internally) with a well defined interface, that is reusable without modification in a variety of contexts.
People call the spring framework heavyweight because there’s a lot of it, and they use some big, expressive classnames.
Actually, it is as light/heavyweight as you want it to be, with a graduated scale of dependence on their apis in your own code. It’s a buffet of reusable library code.
I found that once I embraced IoC as a general rule and spring in particular I wrote vastly more reusable, expressive and well-organised code. JMHO.
(BTW, there are many aspects of spring I do take issue with, bt class naming really isn’t one of them)
I think what people are getting at in the lightweight vs. heavyweight debate has nothing to do with naming or with the complexity of individual classes.
The heavies point out that TransactionAwarePersistenceManagerFactoryProxy is a well-named and internally relatively simple class that is there whenever you need a proxy to factories to manage persistence that are aware of transactions.
The lights are just asking: ok, so why do you need a proxy to factories to begin with?
I tend to come down on the light side of things. If you need proxies to factories with decorations and aspects and blah blah blah, either your program is too big or you haven’t thought through your problem enough and tried to simplify. If your program is too big, maybe you should consider breaking it up into smaller programs with smaller spheres of responsibility that communicate in a standard way. That’s more scalable and easier to make fault-tolerant too.
Simplify, man!
Adam:
What the TransactionAwarePersistenceManagerFactoryProxy is doing is wrapping an externally defined JDO PersistenceManagerFactory (JDO’s name, not Spring’s) in a proxy that is aware of Spring’s transactional infrastructure.
That’s all.
There are analogous classes for dealing with DataSources, JMS and a couple of others IIRC.
What they actually do is simplify your code tremendously – indeed it is the epitomy of “breaking it up into smaller programs with smaller spheres of responsibility that communicate in a standard way”.
And because it wraps third-party code in a proxy that is aware of Spring’s transactional plumbing, your DAO-type code can just assume that the resource you need will be there, ready, at the point you need to use it, and spring takes care of the boilerplate nonsense transparently.
Is Spring becoming the very problem that if was designed to solve ?
AbstractBeanFactoryBasedTargetSourceCreator ContextSingletonBeanFactoryLocator
AspectJAdviceParameterNameDiscoverer UserRoleAuthorizationInterceptor
TransactionAwarePersistenceManagerFactoryProxy SQLStateSQLExceptionTranslator
SimpleBeanFactoryAwareAspectInstanceFactory
Another natural language might help, e.g.
摘要豆厂的靶源造物主，语境独豆厂定位，AspectJ告参数名发现者，用户角色授权拦截，交易意识持久管理厂代理，Sql状况Sql异常翻译，简豆厂意识方面例厂
I have used a lot of the Spring APIs (both Java and .Net) and have not noticed the long names. Is Spring perfect? No. But it is better than most alternatives. Try remoting an application without using something like Spring. It is funny how people dis things like Spring and then go and try to write something like it themselves. A good programmer will try because otherwise they have tons of cut and past code and Chicken/Egg problems. A great programmer will just use someone else’s great work.
@^love*encounter~flow – there are only 26 letters in the English alphabet. So after Z, you have to start using 2 characters.
@Adam – Spring has nothing to with agile nor with “enterprise”. You are, more than likely, writing less maintainable code or “rewriting” Spring.
@PThomas – No, it is not.
@Laurent Szyster – Spring is not just XML. For lack of a good argument you resort to name calling.
@Robb – If one is just doing web apps, then I can see your point. But for those of use who have apps that have many types of interfaces (user and system), then Spring can’t be replaced with Seam.
@Blogger (Kay?) – Stick to what you know – Literature.
Pingback: Is Spring becoming the very problem that if was designed to solve ? | _mindMeld
http://www.mindmeld.ws/blog/2009/07/20/is-spring-becoming-the-very-problem-that-if-was-designed-to-solve/
Nutty, sticking to what one knows isn’t helpful in this case. I’m not a Spring end-user, I’m interested in dynamic Java compilation using Java + Jython and I examine applications of these techniques in Java frameworks including Spring. I wouldn’t do that if I could find lengthy elaborations on this topic in the literature. This work is ( hopefully ) relevant for all parties who are interested in dynamic languages on the JVM.
It is funny how people dis things like Spring and then go and try to write something like it themselves.
There is nothing funny about this. Innovation and trivialization ( figuring out how to build a small and compositional set of primitives, finding new generic schemes, reducing API complexity etc. ) is what drives things forward.
BTW believe it or not, people will applied remoting before the advent of Spring and they’ll do it in future without Spring.
I love how they strike a bit of irony in the mix by adding the word “Simple” in their extra-extra-large type names to make them extra-extra-extra-large, but “simpler” sounding!
The names of classes tend to be long in Spring because they are self-descriptive, almost to a fault. Rather have big names which properly expose the intent of a class than short names which look simpler but hide this intent.
2 points;
1) It’s been said that some design patterns are evidence of language that isn’t expressive enough in it’s syntax. Is Spring showing a need for a change in Java? I say this because @Nutty says “Try remoting an application without using something like Spring.”, but C# (a very near cousin of Java) has built-in remoting, and doesn’t use any special classes to represent remoting proxy objects. It uses interfaces instead.
2) If there’s no english word for a class, you have to use a description. So while you can call ‘a thing with four legs that you ride’ a Horse, what the hell is the english for ‘a thing which converts sql state codes into sql exception objects’? Hence SQLStateSQLExceptionTranslator. Ugly, but I’m at a loss for what else you’d call this.
Few understand how to write self-documenting code. The Spring team does. At a glance, it would appear that Phil Zoio is the only one who has a clue on this forum.
@Nutty (Professor?),
I resort to calling names because Spring fans don’t deserve better.
I reviewed Spring sources, read its manuals and looked at actual Spring applications.
My conclusion is that Spring developers fall in two categories:
Application developers that have to avoid Java heavy development cycle and prefer dynamic configuration through XML. They could do a lot better with a lot less troubles by using Jython or any other decent interpreter running on the JVM. Unfortunately for them, Spring is often a requirement mandated by the local spring gurus.
Spring gurus who live along the line of “why make it simple and stable when you can make it complicated and buggy”. They would be a lot worse without Spring because it’s obscurity and instability is what give them such an easy job: to fix the buggy layers of indirection and abstraction they piled up on top of Java APIs.
Of course I don’t expect to convince nutty gurus of their mistake because “there is no way to reason a man out of an idea he did not reason into in the first place”.
I use spring mainly because the transaction api, wich i find very good, and yes sometimes complex, but better then the others around i know, just the idea of repeating the transaction code is rather boring.
I personally started out as a blatant Spring fanboy and have been associated with it for 4 years – but sadly, I’m beginning to agree with the “Is Spring becoming the very problem that if was designed to solve ?” sentiment – more and more.
What I dislike most about the Spring juggernaut as it exists today is the endorsement of JSF that crept in due to the influence of Keith Donald et. al. At least in the old days, Rod Johnson used to be frank with his opinion on the parts of Java EE that suck. For e.g.
http://forum.springsource.org/showpost.php?s=93ab754b699260b626546cf99345c2f0&p=73776&postcount=1
Compared with:
http://blog.springsource.com/2007/04/21/what-spring-web-flow-offers-jsf-developers/
Dear SpringSource: please don’t treat the Java community like idiots. If you need more info, just google “JSF sucks”.
At this rate they will soon be using bit.ly URL’s for class names.
@Steve,
Is the SQLStateSQLExceptionTranslator really the most obvious solution that comes to your mind? How would you design from scratch?
The OO way:
Write a SpringSQLException that derives from SQLException and add two methods buildMessage() and translate().
The FP way – Java version:
Write a class ExceptionTranslator and define two static methods:
toDataAccessException( SQLException, String, String) -> DataAccessException
buildSQLMessage(SQLException, String, String) -> String
The Spring way?
…
@ Laurent – Funny! Much better. Honestly, I don’t expect you to understand the value of Spring unless you actually use it and do the same sorts of applications/systems that I do and those that need/use Spring. I am not putting you down – just saying Spring isn’t good for some things and you must be doing those. BTW, I don’t fall into either category, but I am a Spring user. I don’t use it 100% – I don’t do Spring MVC.
@kay – You missed the point – by funny i meant “sad”. The key word was “try”. Most people are not capable of doing better than Spring or Guice or … . If you can innovate – then do it. But stop putting down good things. Just show them up. Or shut up.
You also missed the point about remoting. My point was, try to do it on your own. Look at the boilerplate code you end up with. Then try switching protocols. Then try it with Spring. Sure remoting has gone on for years. I’ve done it in VB [shivers down spine].
Spring is becoming the next big elephant to kill ..
— p
I never used spring before but thanks to ur article I’m thinking to