24 ms·

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, suc

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.

mschulze 13y ago
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.
- bsaul 13y ago
  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.
- sfjailbird 13y ago
  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.)
  - chris_wot 13y ago
    Could you give some concrete use cases? Genuinely interested.
  - brown9-2 13y ago
    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.
huherto 13y ago
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.
twistedpair 13y ago
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."
chris_wot 13y ago
Spring represents all that is wrong with Java. 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.
Symmetry 13y ago
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.
milos_cohagen 13y ago
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.
simonw 13y ago
When did Martin Fowler distance himself from IoC?
efsavage 13y ago
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.

mschulze 13y ago

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.

bsaul 13y ago
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.
sfjailbird 13y ago
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.)
- chris_wot 13y ago
  Could you give some concrete use cases? Genuinely interested.
- brown9-2 13y ago
  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.

huherto 13y ago

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.

twistedpair 13y ago

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

chris_wot 13y ago

Spring represents all that is wrong with Java. 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.

Symmetry 13y ago

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.

milos_cohagen 13y ago

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.

simonw 13y ago

When did Martin Fowler distance himself from IoC?

efsavage 13y ago

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.