A bit off topic :
I've used Spring some times ago, and it really made me wonder how the full stack would perform on a benchmark against non-JVM frameworks, even though the JVM is faster than anything else.
This framework really redefined my notion of bloated, although to be fair, i really don't know if the runtime and API part of the framework gave me that feeling, or if it's not mainly due to the extremely painful development environment (aka spring sts : one JVM for the IDE, one JVM for the bean execution, and one virtualization layer on top of the web server thanks to VMWare vFabric...).
In the end, it took me more than 5 minutes to boot STS and get the server run my code, on my fairly recent 4G of RAM MBP.
Out of interest, what stack are you running on? The Spring apps I've worked with in the past (plain Tomcat+Spring) never took more than a few seconds to boot (and most changes could be hot deployed without a restart).
Sorry, I just deleted the parent that you replied too. I felt it was too full of emotion and lacked useful content.
Currently I am working on Spring+Tomcat. Previously we were working on weblogic + spring, that's where the ~50% CPU time measurement came from.
The project where I found myself the most frustrated with Spring was in a simple console app, where Spring became the server container. The application was more or less empty, having only a few database connections, and it took probably about 10 seconds to boot up. I really remember thinking "this is as fast as it will ever be" it only got slower from then on.
Spring is just an XML-based DSL that wires objects together and applies AOP aspects to them.
Your bad experience was with a Spring-branded Eclipse; the open-source IDE that's so slow and bloated Google preferred switching to a proprietary competitor (IntelliJ) for their latest version of the Android IDE.
Yes, but I believe sfjailbird is also right (see comment below) : there's also a vicious "enterprise" culture surrounding that technology that really encourages people to keep going in that direction.
Spring represents all that is wrong with Java. Its main selling point is that it is not J2EE (shallow praise) yet it retains a lot of the awfulness of J2EE, such as XML just for the sake of it (so now you need heavy tool support just to make sure that classes, methods and fields are referred correctly in the XML files). On top of that it introduces layers of craziness that J2EE could only begin to dream of, such as "aspect oriented" configuration and dynamic proxies that enrich and inject and mutate your objects at runtime such that debugging and tracing becomes completely impossible. Even core Spring concepts like "Inversion of Control" are questionable value propositions that even Martin Fowler has distanced himself from.
Java has an ecosystem of enterprise consultants that sell castles in the sky and need to invent complex concepts and technologies to sell themselves and their services. Gullible enterprise developers eat it up and mimmick them. Ignorant CTOs buy their stuff. I'm pissed off about it because Java is basically cool technology but the culture is infected with these bloodsuckers who give it a bad name and do nothing for advancing the state of the language and ecosystem.
How long has it been that you used Spring? You don't need that much XML for a Spring 3.0 application. Almost everything can be done with annotations.
Why do you compare Spring with J2EE when in fact JEE took a lot of the good stuff from Spring?
The main point of Spring is to help develop consistent applications with enterprise requirements (integration, security, batch jobs, mvc, ...) and it does that incredibly well. Especially integration in a nightmare of systems at a large corporation.
I do agree that IOC coupled with strong interface definitions and enforcement make a good starting point for building enterprise components in large corporations.
Yet, after using Spring for a while, i really wondered how come there couldn't be any simpler solutions to that problem: any compiled language with a good support for interfaces should be able to reach that objective.
I think the bloat came from wanting to decouple compilation time from component assembling time, using xml files. I never understood the reason for that choice (who in its right mind would change a component without recompiling for type checking and retesting the code anyway ?).
I suppose it probably was the easiest way to accomplish that in Java at some point, and i'm really happy to see that latest Spring versions enable you to use Java configuration classes instead. But as enterprise means long-time support and never ending backward compatibility, i really doubt the bloat culture will fade away any time soon.
I wouldn't say incredibly well, more like a passing mark. In fact I would compare Spring to Maven: It gets the job done, it's probably even the best of the alternatives, it still leaves a bad taste in the mouth.
I find that for many of the configuration use cases that Spring is supposed to solve I am better off doing things programmatically (heresy in the Java world). Yes, this can be done and still have testable, decoupled configuration. (As for changing configuration on the fly, nobody does that. It is a leftover from the "Deployer" role defined by Sun's J2EE specification.)
The JavaConfig stuff in the latest versions of Spring is really great, and I think meets your goal of being able to do the configuration programmatically. Take a look if you have not already.
Like in many aspects of life. People tend to take ideas and extend them to the point where their cost is higher than their value. But it is the job of a good developer/architect to find the happy point where they are valuable.
Ugh... AOP. I've seen it implemented so wrongly that it makes debugging and understanding the code near impossible. Add in wireup at startup and you can wait a good long time for app startup.
If they could have dumped that, the world would be a better place. Note: it's a good idea in theory, just not in practice.
"Spring; Making simple things trivial and complex things nil possible."
That's a big claim, but can you back it up? Let's see...
Its main selling point is that it is not J2EE (shallow praise)
No, no it's not. It's main claim to fame is that it was one of the first IoC containers and did a lot if things right that earlier versions of J2EE didn't (Container Managed Transactions, anyone?).
In fact, Spring has influenced quite a lot of the direction of J2EE. Just look at the @Inject annotation, etc.
yet it retains a lot of the awfulness of J2EE, such as XML just for the sake of it (so now you need heavy tool support just to make sure that classes, methods and fields are referred correctly in the XML files).
Except you don't. You can write all configuration as code if you wish. It makes extensive use of annotations. You have no idea what you are talking about.
Incidentally, what sort of "heavy tool support" are you referring to? The XML syntax isn't that heavy, and things like JetBrains or Eclipse handles it fine. And I've never had to directly manipulate the XML programmatically, nor have I ever had to extend or even read the XSD files that go along with it. Nor have I had to do anything insane like use XQuery or XSLT.
On top of that it introduces layers of craziness that J2EE could only begin to dream of, such as "aspect oriented" configuration and dynamic proxies that enrich and inject and mutate your objects at runtime such that debugging and tracing becomes completely impossible.
You're doing it wrong then. AOP is not only a perfectly reasonable and sensible way of doing things, but by default you don't need to rewrite bytecode with CGLIB as it uses a proxy mechanism. Should you wish to use CGLIB, the option is there though.
Even core Spring concepts like "Inversion of Control" are questionable value propositions that even Martin Fowler has distanced himself from.
Are you serious? Inversion of Control, when done properly, is extremely powerful. It's a fantastic way of decoupling components in a flexible and powerful way.
But please, do let us in on why it is a "questionable value proposition", I'm genuinely curious as to some actual technical reasons behind this claim.
Java has an ecosystem of enterprise consultants that sell castles in the sky and need to invent complex concepts and technologies to sell themselves and their services.
Any sufficiently advanced framework or technology has this issue. Why just pick on Spring? It's hardly the fault of the framework though.
Gullible enterprise developers eat it up and mimmick them. Ignorant CTOs buy their stuff.
OK...
I'm pissed off about it because Java is basically cool technology but the culture is infected with these bloodsuckers who give it a bad name and do nothing for advancing the state of the language and ecosystem.
I'm interested in what you like about Java, and how Spring has blocked it's advancement; that's one hell of a big claim, but you haven't done anything to support your assertions other than make some broad and sweeping statements that aren't backed by any real reasoning.
Ok, I have a single concrete example of Spring's AOP everywhere being a questionable value proposition. If we have a look inside a class, which appears again and again on our overburdened stack traces, JdkDynamicAopProxy.
Whenever you call an aspected object in Spring it likely goes through an object of this type first. On line 177 we find this
// massage return value if necessary
if (retVal != null && retVal == target) {
// Special case: it returned "this".
// Note that we can't help if the target sets
// a reference to itself in another returned object.
retVal = proxy;
}
Here we can see Spring trying to work around an edge case when a proxied object returns itself from a method call. It is noted that if the method puts a reference to itself into another object and returns it the unproxied version of the object will be exposed.
It is this kind of leakiness that contributes to a sense of horror when dealing with Spring. The abstractions provided by Spring are so pervasive and invisible that this makes me very anxious. I really feel that when dealing with the large enterprise class applications, that Spring is aiming for, something direct and _very_ explicit and _visible_ would be far far better.
In this case though, wouldn't a different style of AOP be more useful? Perhaps something that doesn't use a proxy but rewrites the bytecode, like CGLIB? Not sure, not experienced enough in this I'm afraid.
Is it hard to work around the corner case? Interested...
Different people have very different views on this. It seems to be something which touches at an emotional level, or just exposes the way different people think about programming.
My opinion is that aspects are a mistake in general. I think that all of the situations that I have seen aspects used they have saved roughly 5 lines of boiler plate in exchange for creating an invisible layer of very fragile code which ties you hard to your Spring container.
But I really like explicit code, so you would expect me not to like aspects. I do strongly think that aspects are really solving a 'not very hard' problem while exacerbating the biggest problem I have, which is not understanding the codebase.
The thing I truly hate about Spring are the stacks. Good lord, I cannot find my code in that skyscraper of abstract proxied garbage. If you want a good technical reason to dislike Spring it's good to note that deep stacks place a larger burden on your garbage collector, in this instance Spring is truly a degenerate case.
W.r.t. gclib I don't want my code byte weaved. Ever. I want it to do what is says on the tin. Always. I am very willing to write and read more code to do this. If too much code is becoming a problem don't turn to Spring - try removing some of your AbstractFactoryFactories first :) (tongue sort of in cheek)
If you don't like DI or AOP, then you can just code plain Java.
If you like DI but not AOP, then something like Guice or plain Java and some self-discipline would probably work better for you.
If you like DI and AOP, then you can let Spring get you as close to proper AOP as Java allows without weaving, or you can use the same syntax to do compile-time weaving to get a non-leaky abstraction
All these are just choices to make; it seems like you're more fighting against the fact that you don't like how the 'industry' is making these 'enterprise standard' choices for you.
On a technical level it's more like criticising Rails for using meta-programming everywhere, or C because it's so low-level (i.e. that's what they were designed for! If that's not what you need, don't use it!)
I recently got involved with a fair sized Java project recently (the backend directing our robots), and while my impression of Spring is that it's a bit of a crawling horror, IoC is actually pretty darn useful. The big problem is all the runtime string comparisons, when I'm using Java I want typos discovered at compile time not runtime.
I haven't used it, but my impression is that I'd be much happier with something like Guice that is lighter weight and actually does compile-time typechecking.
Spring can be configured with zero XML. And it's numerous components can be used a-la-carte. Far and away it's the IOC and TX mgmt at the core. The frameworks source is pretty straight forward and it has excellent docs.
If you are looking at "big" frameworks in other language eco-systems, I can't help but think Spring should be considered quality stuff.
You have to keep in mind Spring is a Java framework, and therefore should reflect the stable, conservative nature of the language itself.
Spring stack traces can get long'ish, but they are very easy to understand. Take a look at a Clojure stack trace and you'll realize how simple Spring's are.
I work with Spring daily, and I haven't written a line of Spring XML in, literally, years. Granted I don't use all of the modules it offers, some of which may still use XML, but the best part about Spring is that you can pick and choose what'd you like, and replace/extend where you need to.
31 comments
[ 3.5 ms ] story [ 67.5 ms ] threadThis framework really redefined my notion of bloated, although to be fair, i really don't know if the runtime and API part of the framework gave me that feeling, or if it's not mainly due to the extremely painful development environment (aka spring sts : one JVM for the IDE, one JVM for the bean execution, and one virtualization layer on top of the web server thanks to VMWare vFabric...).
In the end, it took me more than 5 minutes to boot STS and get the server run my code, on my fairly recent 4G of RAM MBP.
Currently I am working on Spring+Tomcat. Previously we were working on weblogic + spring, that's where the ~50% CPU time measurement came from.
The project where I found myself the most frustrated with Spring was in a simple console app, where Spring became the server container. The application was more or less empty, having only a few database connections, and it took probably about 10 seconds to boot up. I really remember thinking "this is as fast as it will ever be" it only got slower from then on.
Your bad experience was with a Spring-branded Eclipse; the open-source IDE that's so slow and bloated Google preferred switching to a proprietary competitor (IntelliJ) for their latest version of the Android IDE.
I would not judge Spring the Framework by Spring the IDE (which is a bunch of plugins on top of Eclipse). The Spring integration in IntelliJ is great.
Excellent resource for anyone using Spring.
Java has an ecosystem of enterprise consultants that sell castles in the sky and need to invent complex concepts and technologies to sell themselves and their services. Gullible enterprise developers eat it up and mimmick them. Ignorant CTOs buy their stuff. I'm pissed off about it because Java is basically cool technology but the culture is infected with these bloodsuckers who give it a bad name and do nothing for advancing the state of the language and ecosystem.
Why do you compare Spring with J2EE when in fact JEE took a lot of the good stuff from Spring?
The main point of Spring is to help develop consistent applications with enterprise requirements (integration, security, batch jobs, mvc, ...) and it does that incredibly well. Especially integration in a nightmare of systems at a large corporation.
Yet, after using Spring for a while, i really wondered how come there couldn't be any simpler solutions to that problem: any compiled language with a good support for interfaces should be able to reach that objective.
I think the bloat came from wanting to decouple compilation time from component assembling time, using xml files. I never understood the reason for that choice (who in its right mind would change a component without recompiling for type checking and retesting the code anyway ?).
I suppose it probably was the easiest way to accomplish that in Java at some point, and i'm really happy to see that latest Spring versions enable you to use Java configuration classes instead. But as enterprise means long-time support and never ending backward compatibility, i really doubt the bloat culture will fade away any time soon.
I find that for many of the configuration use cases that Spring is supposed to solve I am better off doing things programmatically (heresy in the Java world). Yes, this can be done and still have testable, decoupled configuration. (As for changing configuration on the fly, nobody does that. It is a leftover from the "Deployer" role defined by Sun's J2EE specification.)
If they could have dumped that, the world would be a better place. Note: it's a good idea in theory, just not in practice.
"Spring; Making simple things trivial and complex things nil possible."
That's a big claim, but can you back it up? Let's see...
Its main selling point is that it is not J2EE (shallow praise)
No, no it's not. It's main claim to fame is that it was one of the first IoC containers and did a lot if things right that earlier versions of J2EE didn't (Container Managed Transactions, anyone?).
In fact, Spring has influenced quite a lot of the direction of J2EE. Just look at the @Inject annotation, etc.
yet it retains a lot of the awfulness of J2EE, such as XML just for the sake of it (so now you need heavy tool support just to make sure that classes, methods and fields are referred correctly in the XML files).
Except you don't. You can write all configuration as code if you wish. It makes extensive use of annotations. You have no idea what you are talking about.
Incidentally, what sort of "heavy tool support" are you referring to? The XML syntax isn't that heavy, and things like JetBrains or Eclipse handles it fine. And I've never had to directly manipulate the XML programmatically, nor have I ever had to extend or even read the XSD files that go along with it. Nor have I had to do anything insane like use XQuery or XSLT.
On top of that it introduces layers of craziness that J2EE could only begin to dream of, such as "aspect oriented" configuration and dynamic proxies that enrich and inject and mutate your objects at runtime such that debugging and tracing becomes completely impossible.
You're doing it wrong then. AOP is not only a perfectly reasonable and sensible way of doing things, but by default you don't need to rewrite bytecode with CGLIB as it uses a proxy mechanism. Should you wish to use CGLIB, the option is there though.
Even core Spring concepts like "Inversion of Control" are questionable value propositions that even Martin Fowler has distanced himself from.
Are you serious? Inversion of Control, when done properly, is extremely powerful. It's a fantastic way of decoupling components in a flexible and powerful way.
But please, do let us in on why it is a "questionable value proposition", I'm genuinely curious as to some actual technical reasons behind this claim.
Java has an ecosystem of enterprise consultants that sell castles in the sky and need to invent complex concepts and technologies to sell themselves and their services.
Any sufficiently advanced framework or technology has this issue. Why just pick on Spring? It's hardly the fault of the framework though.
Gullible enterprise developers eat it up and mimmick them. Ignorant CTOs buy their stuff.
OK...
I'm pissed off about it because Java is basically cool technology but the culture is infected with these bloodsuckers who give it a bad name and do nothing for advancing the state of the language and ecosystem.
I'm interested in what you like about Java, and how Spring has blocked it's advancement; that's one hell of a big claim, but you haven't done anything to support your assertions other than make some broad and sweeping statements that aren't backed by any real reasoning.
Whenever you call an aspected object in Spring it likely goes through an object of this type first. On line 177 we find this
Here we can see Spring trying to work around an edge case when a proxied object returns itself from a method call. It is noted that if the method puts a reference to itself into another object and returns it the unproxied version of the object will be exposed.It is this kind of leakiness that contributes to a sense of horror when dealing with Spring. The abstractions provided by Spring are so pervasive and invisible that this makes me very anxious. I really feel that when dealing with the large enterprise class applications, that Spring is aiming for, something direct and _very_ explicit and _visible_ would be far far better.
In this case though, wouldn't a different style of AOP be more useful? Perhaps something that doesn't use a proxy but rewrites the bytecode, like CGLIB? Not sure, not experienced enough in this I'm afraid.
Is it hard to work around the corner case? Interested...
My opinion is that aspects are a mistake in general. I think that all of the situations that I have seen aspects used they have saved roughly 5 lines of boiler plate in exchange for creating an invisible layer of very fragile code which ties you hard to your Spring container.
But I really like explicit code, so you would expect me not to like aspects. I do strongly think that aspects are really solving a 'not very hard' problem while exacerbating the biggest problem I have, which is not understanding the codebase.
The thing I truly hate about Spring are the stacks. Good lord, I cannot find my code in that skyscraper of abstract proxied garbage. If you want a good technical reason to dislike Spring it's good to note that deep stacks place a larger burden on your garbage collector, in this instance Spring is truly a degenerate case.
W.r.t. gclib I don't want my code byte weaved. Ever. I want it to do what is says on the tin. Always. I am very willing to write and read more code to do this. If too much code is becoming a problem don't turn to Spring - try removing some of your AbstractFactoryFactories first :) (tongue sort of in cheek)
Since I work with Spring every day it brings up some strong emotions.
If you like DI but not AOP, then something like Guice or plain Java and some self-discipline would probably work better for you.
If you like DI and AOP, then you can let Spring get you as close to proper AOP as Java allows without weaving, or you can use the same syntax to do compile-time weaving to get a non-leaky abstraction
All these are just choices to make; it seems like you're more fighting against the fact that you don't like how the 'industry' is making these 'enterprise standard' choices for you.
On a technical level it's more like criticising Rails for using meta-programming everywhere, or C because it's so low-level (i.e. that's what they were designed for! If that's not what you need, don't use it!)
I haven't used it, but my impression is that I'd be much happier with something like Guice that is lighter weight and actually does compile-time typechecking.
If you are looking at "big" frameworks in other language eco-systems, I can't help but think Spring should be considered quality stuff.
You have to keep in mind Spring is a Java framework, and therefore should reflect the stable, conservative nature of the language itself.
Spring stack traces can get long'ish, but they are very easy to understand. Take a look at a Clojure stack trace and you'll realize how simple Spring's are.