5 ms·

Can you give us some evidence why Spring is "unequivocal and absolute garbage"?

mbreese 14y ago
I haven't used it for a few years, but I always found it funny that a project that was supposed to make Java application development easier and more agile than J2EE ended up being just as large, if not larger. Core Spring did a lot for dependency injection, which was a big shift in thought. However, for dependency management, I'd go with something like Guice today.
exelib 14y ago
Spring was innovative in 2008. Now, Spring is overbloat, buggy (look at request-mapper) and have old, sensless integration to others modules, see spring-data for NoSQL, or try integrate last version of Velocity with last version of Spring. And additionaly, all, what you can do with Spring, you can do with JEE.
- strlen 14y ago
  Yes, I was careful to say "J2EE" and not "JEE". WebBeans/CDI in Java EE 6 are quite decent. JSR 330 seems as if they just standardized on Guice. JSR 318 is quite good as well: I highly recommend using Jersey if you're building a REST API.
- edwinnathaniel 14y ago
  I think collectively we should point out the specific Spring modules as opposed to say that "Spring is overbloat and buggy". Some of Spring modules seem to be quite stable enough. Others, the newer modules, will take time to be more mature. Spring's goal have always been to be the 'glue layer' of the Java standards. Of course, now they want to be the 'glue layer' of everything, including Spring-Data for NoSQL (Neo4J and co.). Speaking of which, your last statement is partly correct if only Spring == Spring Core. There's no MVC (in the sense of ASP.NET MVC or Rails MVC) in JEE yet (yet because things might change in the future). JEE has 2-3 technology covering the "VC" options: JSP, Servlet, and JSF. None of these are similar to that of ASP.NET MVC or Rails MVC.
  - exelib 14y ago
    I pointed one module out - Spring-Velocity integration. "Of course, now they want to be the 'glue layer' of everything, including Spring-Data for NoSQL (Neo4J and co.)." Why do you need this? It's just Java and you can... just use it. Without glue. "Speaking of which, your last statement is partly correct if only Spring == Spring Core. There's no MVC (in the sense of ASP.NET MVC or Rails MVC) in JEE yet (yet because things might change in the future). JEE has 2-3 technology covering the "VC" options: JSP, Servlet, and JSF. None of these are similar to that of ASP.NET MVC or Rails MVC." What do you mean with MVC exactly? This is just buzz word. MVC Model 2 Architecture (and now you have Servlet 3) is good replacement for Spring MVC. JSR303 and JPA (or other) is good replacement for 'M' (and of cource, in Spring it's same way). We talk about Spring or Rails/ASP? And of course, here solutions in Play/Play2. Really, you don't need Spring. It's 'Bug layer'.
    - edwinnathaniel 14y ago
      You pointed one module, as an example that describes the whole Spring as one unified framework. Spring consists of multiple modules that you absolutely _don't_ have to use. This is where, I think, you misunderstood Spring. When it comes to the modules, i.e.: Spring Core, Spring Transaction, Spring-Data sub-modules, Spring eventually use the JDK and/or 3rd-party API (possibility, in the case of Neo4J etc). Yes, you can use JDBC, JTA, JPA, and Neo4J API directly. For sure. But Spring has always wanted to become an alternative to using them directly by providing more features and supposedly better programming experience. This is what I meant by _glue_. You're absolutely correct: you can use those libraries directly without Spring. But if Spring modules provide me with better programming model, more features on top of barebone implementations, why would I not use Spring modules? This, again, something that you seem don't quite see from Spring. Let's say MVC is a buzzword and start from there. If you look at ASP.NET MVC and Rails MVC, they provide a programming model where you have a request mapper/route that maps a request to a method in your controller. MVC Model 2 architecture does not provide you with that. MVC Model 2 architecture provides you 1:1 mapping between a URL with Servlet. Which means if you do a simple CRUD a'la Resource, you can either have 1 Servlet per Resource that acts as a dispatcher for the CRUD operation via either query parameters or multiple Servlets. Again, if you choose to live with that, that's your choice. Spring offers a better programming model than MVC Model 2 architecture and there are people out there that prefer it. Spring also offers WebFlow, a module on top of Spring-MVC that helps building Wizard or Shopping Chart that involves lifecycle/steps. Can you live without it? For sure. Roll your own. That's one, second, in Rails MVC, you can set the content negotiation to send back either JSON, XML, or HTML. You can do this with JAX-RS but that is a separate "servlet" per-se. If you want your API to live in a different part of your systems, this is acceptable. But if you want all of the request comes from one entry-point, you have to work harder than that. Calling Spring as a 'Bug Layer' reminds me of this article: http://www.codinghorror.com/blog/2008/03/the-first-rule-of-programming-its-always-your-fault.html http://www.codinghorror.com/blog/2008/03/the-first-rule-of-p...
strlen 14y ago
Well, for starters the whole idea of programming in XML. That and gems such as http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/aop/config/SimpleBeanFactoryAwareAspectInstanceFactory.html http://static.springsource.org/spring/docs/2.5.x/api/org/spr... or http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html http://static.springsource.org/spring/docs/2.5.x/api/org/spr... Of course I can't a priori prove that Spring is garbage, much like I can't a priori prove that it's better to be healthy and rich than to be poor and sick. It is a judgement call, but a judgement call that I believe I'm qualified to make, having worked with a large Spring codebase for 2.5 years.
- samspot 14y ago
  You can ditch the xml almost entirely in spring 3, which I've been using for 2 years now. All you need is 50-100 boilerplate lines and the rest is annotations. I agree that 2.x was xml hell, but it is worlds better now.
  - ricardobeat 14y ago
    > All you need is 50-100 boilerplate lines That answers "Why not Java?" perfectly ;)
    - prpatel 14y ago
      Java is a verbose language, but it's still awesome for a large category of projects. Are you a rails guy? how about those 50-500 lines of boilerplate code in the config files? Same thing as the Spring config files. Does that lead me to say "Why not Rails?" No it doesn't! Saying it politely as possible: don't be a hater.
  - samspot 14y ago
    I sense sarcasm, but 100 lines of xml in a 200,000 line web application is wonderful. And this xml is specifiying critical things like database connection and pool settings, transaction management, entity caching, and more. You are going to be configuring this stuff no matter what platform you use, and the simpler it is the better.

I haven't used it for a few years, but I always found it funny that a project that was supposed to make Java application development easier and more agile than J2EE ended up being just as large, if not larger. Core Spring did a lot for dependency injection, which was a big shift in thought. However, for dependency management, I'd go with something like Guice today.

exelib 14y ago

Spring was innovative in 2008. Now, Spring is overbloat, buggy (look at request-mapper) and have old, sensless integration to others modules, see spring-data for NoSQL, or try integrate last version of Velocity with last version of Spring. And additionaly, all, what you can do with Spring, you can do with JEE.

strlen 14y ago
Yes, I was careful to say "J2EE" and not "JEE". WebBeans/CDI in Java EE 6 are quite decent. JSR 330 seems as if they just standardized on Guice. JSR 318 is quite good as well: I highly recommend using Jersey if you're building a REST API.
edwinnathaniel 14y ago
I think collectively we should point out the specific Spring modules as opposed to say that "Spring is overbloat and buggy". Some of Spring modules seem to be quite stable enough. Others, the newer modules, will take time to be more mature. Spring's goal have always been to be the 'glue layer' of the Java standards. Of course, now they want to be the 'glue layer' of everything, including Spring-Data for NoSQL (Neo4J and co.). Speaking of which, your last statement is partly correct if only Spring == Spring Core. There's no MVC (in the sense of ASP.NET MVC or Rails MVC) in JEE yet (yet because things might change in the future). JEE has 2-3 technology covering the "VC" options: JSP, Servlet, and JSF. None of these are similar to that of ASP.NET MVC or Rails MVC.
- exelib 14y ago
  I pointed one module out - Spring-Velocity integration. "Of course, now they want to be the 'glue layer' of everything, including Spring-Data for NoSQL (Neo4J and co.)." Why do you need this? It's just Java and you can... just use it. Without glue. "Speaking of which, your last statement is partly correct if only Spring == Spring Core. There's no MVC (in the sense of ASP.NET MVC or Rails MVC) in JEE yet (yet because things might change in the future). JEE has 2-3 technology covering the "VC" options: JSP, Servlet, and JSF. None of these are similar to that of ASP.NET MVC or Rails MVC." What do you mean with MVC exactly? This is just buzz word. MVC Model 2 Architecture (and now you have Servlet 3) is good replacement for Spring MVC. JSR303 and JPA (or other) is good replacement for 'M' (and of cource, in Spring it's same way). We talk about Spring or Rails/ASP? And of course, here solutions in Play/Play2. Really, you don't need Spring. It's 'Bug layer'.
  - edwinnathaniel 14y ago
    You pointed one module, as an example that describes the whole Spring as one unified framework. Spring consists of multiple modules that you absolutely _don't_ have to use. This is where, I think, you misunderstood Spring. When it comes to the modules, i.e.: Spring Core, Spring Transaction, Spring-Data sub-modules, Spring eventually use the JDK and/or 3rd-party API (possibility, in the case of Neo4J etc). Yes, you can use JDBC, JTA, JPA, and Neo4J API directly. For sure. But Spring has always wanted to become an alternative to using them directly by providing more features and supposedly better programming experience. This is what I meant by _glue_. You're absolutely correct: you can use those libraries directly without Spring. But if Spring modules provide me with better programming model, more features on top of barebone implementations, why would I not use Spring modules? This, again, something that you seem don't quite see from Spring. Let's say MVC is a buzzword and start from there. If you look at ASP.NET MVC and Rails MVC, they provide a programming model where you have a request mapper/route that maps a request to a method in your controller. MVC Model 2 architecture does not provide you with that. MVC Model 2 architecture provides you 1:1 mapping between a URL with Servlet. Which means if you do a simple CRUD a'la Resource, you can either have 1 Servlet per Resource that acts as a dispatcher for the CRUD operation via either query parameters or multiple Servlets. Again, if you choose to live with that, that's your choice. Spring offers a better programming model than MVC Model 2 architecture and there are people out there that prefer it. Spring also offers WebFlow, a module on top of Spring-MVC that helps building Wizard or Shopping Chart that involves lifecycle/steps. Can you live without it? For sure. Roll your own. That's one, second, in Rails MVC, you can set the content negotiation to send back either JSON, XML, or HTML. You can do this with JAX-RS but that is a separate "servlet" per-se. If you want your API to live in a different part of your systems, this is acceptable. But if you want all of the request comes from one entry-point, you have to work harder than that. Calling Spring as a 'Bug Layer' reminds me of this article: http://www.codinghorror.com/blog/2008/03/the-first-rule-of-programming-its-always-your-fault.html http://www.codinghorror.com/blog/2008/03/the-first-rule-of-p...

strlen 14y ago

Well, for starters the whole idea of programming in XML. That and gems such as http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/aop/config/SimpleBeanFactoryAwareAspectInstanceFactory.html http://static.springsource.org/spring/docs/2.5.x/api/org/spr... or http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/aop/framework/AbstractSingletonProxyFactoryBean.html http://static.springsource.org/spring/docs/2.5.x/api/org/spr... Of course I can't a priori prove that Spring is garbage, much like I can't a priori prove that it's better to be healthy and rich than to be poor and sick. It is a judgement call, but a judgement call that I believe I'm qualified to make, having worked with a large Spring codebase for 2.5 years.

samspot 14y ago
You can ditch the xml almost entirely in spring 3, which I've been using for 2 years now. All you need is 50-100 boilerplate lines and the rest is annotations. I agree that 2.x was xml hell, but it is worlds better now.
- ricardobeat 14y ago
  > All you need is 50-100 boilerplate lines That answers "Why not Java?" perfectly ;)
  - prpatel 14y ago
    Java is a verbose language, but it's still awesome for a large category of projects. Are you a rails guy? how about those 50-500 lines of boilerplate code in the config files? Same thing as the Spring config files. Does that lead me to say "Why not Rails?" No it doesn't! Saying it politely as possible: don't be a hater.
- samspot 14y ago
  I sense sarcasm, but 100 lines of xml in a 200,000 line web application is wonderful. And this xml is specifiying critical things like database connection and pool settings, transaction management, entity caching, and more. You are going to be configuring this stuff no matter what platform you use, and the simpler it is the better.