Arif Rachim: Five Reasons I think I won't use Spring

Discussions

News: Arif Rachim: Five Reasons I think I won't use Spring

  1. Arif Rachim has posted "5 Reasons why I think I will not use Spring," detailing some issues he has with Spring: bloated configuration, XML configuration, lack of strong type checking, performance of the container, and the Spring binding process (i.e., applications that use Spring *must* use Spring...) Most of the issues he details are with reference to the configuration of Spring. For example (with edits for grammar):
    1. Spring configuration is bloated.
    My team develops enterprise application using a Dependency Injection framework. There are more than 1500 classes in that project, and separated to more than eleven modules. To my experience in a real world, "we made service objects less than the objects that depend on that service." If we use Spring, when we made 1000 actions that depend in 100 service, it means we have to make configuration on 1000 beans that depend on 100 services. The configuration gets worse if the actions continue growing in numbers - we must be even more careful when we want to refactor something, as we dont want to break existing code. You might start thinking using autowire by type - no, that would be a bad idea. Then why not use autowire by name? That sounds silly. What if we have different names in configuration for different object? Well, I guess that's going to be another long nite at the office.
    His fifth concern is probably the most relevant:
    Spring is a container that just promises to help us build loosely coupled technology, Spring does not really concern that much about tightly coupled. I'm very sure that once we use spring lib other than spring-core.jar that means our application cannot live without Spring.
    There's no "standard" way to get elements from Spring without depending on Spring, nor is there a clear path to having transparent use of such a library. (That said, Struts 2 is able to use Spring to locate actions through a very simple configuration. If Struts 2 can do it...) What do you think?

    Threaded Messages (89)

  2. I agree that the Spring configuration is verbose. With the introduction of domain specific syntax in Spring 2 it has become a little better, but there is still room for improvement. Getting rid of the XML would be a good step forward and that is why I'm currently playing with the DSL for Spring that Grails provides. Although the documentation is very limited, I see many advantages (less typing, groovy language features combined with the dsl.. so you are not forced to create beanfactories for simple stuff like adding listeners to a bean). But the quality of this part of grails really needs to improve to make it usable for mainstream developers. And for the Spring dependency: Spring is much more than just an IOC container. It provides integration for a lot of api's. As soon as you are going to replace Spring by something else, this integration has to be replaced also. If you are going to use a very very lightweight IOC container, you will have to set up this integration functionality yourself. It also means that your code still depends on some integration code. I would like to see where dynamic language like (J)Ruby and Groovy can take Spring. Spring for the integration logic, and a powerful and extendable DSL for bean creation.
  3. I've never understood why creating objects is so burdensome that a complete other framework with a O(n) configuration burden is required. Just create the darn objects.
  4. I've never understood why creating objects is so burdensome that a complete other framework with a O(n) configuration burden is required. Just create the darn objects.
    Another little boy shouting "the emperor has no clothes". You better watch out.
  5. That's right. If you need objects from jndi, just copy and paste the code that makes the lookup into every class. I mean, how hard is that? Or write a 3000 lines service locator and call it from everywhere. It's reeally simple to do.
  6. I've never understood why creating objects is so burdensome that a complete other framework with a O(n) configuration burden is required. Just create the darn objects.
    Don't worry, you will understand it very clearly when you start unit testing your first large project.
  7. Don't worry, you will understand it very clearly when you start unit testing your first large project.
    Arrogance becomes you. I've unit tested many large projects. It goes something like: Object test= new Object(new OtherObjects); ASSERT(test.goodness()) I simply use the mocks where necessary. If I am using factories or singletons then I tell the factory what to return for this test. It's all quite simple.
  8. I've never understood why creating objects is so burdensome that a complete other framework with a O(n) configuration burden is required. Just create the darn objects.


    Don't worry, you will understand it very clearly when you start unit testing your first large project.
    It is not only testing, if you have to work with simulated modules because some third party is not on time, or the schedule demands some work with dependencies into not yet existing code, this is also heavens sent.
  9. It is not only testing, if you have to work with simulated modules because some third party is not on time, or the schedule demands some work with dependencies into not yet existing code, this is also heavens sent.
    Yes of course not, but considering the trollish nature of the post i was replying to i didn't feel like spending time writing an essay. As a side note; one more use is assembling different versions/configurations of same software for different customers. I have not used Seam or Guice in real projects, but it seems to me that their approach might make this difficult, or at least somewhat 'unnatural'?
  10. I think you not getting the mood. You concern with your design and let the framework do creation and the wiring. When you work in a medium or large project you can reduce the pains of initial startup and object creation and make it in an elegant way.
  11. When you work in a medium or large project you can reduce the pains of initial startup and object creation and make it in an elegant way.
    What is more elegant, one place where you can actually see how your application is wired together in code, or hundreds of xml files scattered across a file system? Your system should be in the code.
  12. > When you work in a medium or large project you can reduce the pains of initial startup and object creation and make it in an elegant way.

    What is more elegant, one place where you can actually see how your application is wired together in code, or hundreds of xml files scattered across a file system? Your system should be in the code.
    ???? Who has hundreds of XML files vs. hundreds of class files? You? I'd love to see that uberclass! :-)
  13. hundreds of xml files scattered across a file system
    Hundreds? Scattered? Please. "your system should be in the code": the xml config is a way to express structure, your system is in the code, its structure in the xml config. I don't know if xml is "elegant": what I'm pretty sure of, is that there is no way to write code in java that defines a structure in a more "elegant" way. In my view an algorithm implementation may be elegant, a class structure may be elegant: the declaration of a structure is hardly something where you may put the intellectual value that qualifies something as "elegant". XML for defining structures is not bad: the myth that XML configuration is a hell stems from having lots of different configuration files from different technologies, with different documentations, different approaches, different implementations, different locations and so on. This depends on the particular nature of java development, often made of different technologies assembled together. What spring did, in this context, was to offer a path to a way to have all those different technologies be wired together and configured in an homogeneous way. At the beginning of our project we defined a location in our webapps where ALL the configuration files must reside, and we stick to it: it's not "scattered", it's in WEB-INF/cfg. If a technology forces us to put config somewhere else (WEB-INF/classes) we don't use it, period. If a technology force us to use their particular configuration without being able to be configured by spring, we look at it with suspect. When we started using spring for wiring struts actions, we quickly realized that it's unpractical having to provide duplicate bean definitions for every action: so we agreed on an autowire strategy and coded a simple extension so that we can override particular beans. If you think you have to write thousands of configuration files if you use spring, you're wrong: you have to write thousands of config files only if you don't have a clue, but Spring has no part in it. XML is not bad. If you don't like it, just use one of the other configuration styles (java, annotations).
  14. XML for defining structures is not bad:
    Are they typed check? Do they show up in the code? Are they refactorable? Do I know where they are in the file system? How do I tell what all the magic elements mean or do? That's all bad to me.
    If a technology force us to use their particular configuration without being able to be configured by spring
    Then it seems spring should just be folded into the language because there is not allowed deviation.
    If you think you have to write thousands of configuration files if you use spring
    Either there's so much to configure you need help or there's so little that you don't.
  15. > XML for defining structures is not bad:

    Are they typed check? Do they show up in the code? Are they refactorable? Do I know where they are in the file system? How do I tell what all the magic elements mean or do?

    That's all bad to me.

    > If a technology force us to use their particular configuration without being able to be configured by spring

    Then it seems spring should just be folded into the language because there is not allowed deviation.

    > If you think you have to write thousands of configuration files if you use spring

    Either there's so much to configure you need help or there's so little that you don't.
    Yes they are refactorable. Yes, you get errors if you try to inject something that isn't of the right type. If you are using the XML and you don't know where it is, the fault lies in you, not Spring. Again, if you think you need thousands of configuration files, you don't understand the technology and are wise to avoid it.
  16. Please show some code?[ Go to top ]

    It would be helpful if someone could show some code that demonstrated the benefits. Do you have some that makes it clear ? I simply don't see when using springified projects.
  17. Re: Please show some code?[ Go to top ]

    It would be helpful if someone could show some code that demonstrated the benefits. Do you have some that makes it clear ? I simply don't see when using springified projects.
    Then don't use it. If you don't understand it, don't use it. You wouldn't put a gun in your mouth, right? However, a gun pointed at your enemy is a powerful weapon. IMO, the usefulness of Spring is pretty obvious. Check out that old Introduction to the Spring Framework paper hosted on this site. If, after reading that, you don't agree with Spring's philosophy, then it simply isn't the tool for you. However, there are plenty of people who *do* understand it and use it.
  18. How about this for benefits[ Go to top ]

    Here's one huge benefit of spring: public interface MyServiceDao { @Transactional(propagation=Propagation.REQUIRED) public void addMyObject(MyObject myObject); } public class MyServiceDaoImpl extends HibernateDaoSupport { public void addMyObject(MyObject myObject) { getHibernateTemplate().save(myObject); } And in your spring beans file: "Magically", your dao has proper transaction management, jdbc/hibernate resource handling, etc.... Think of all the code you'd be writing to handle transaction management by hand, especially jta based transactions. The power of spring is not entirely in the IOC container. There are many IOC containers available which can do the job (hivemind, guice, picocontainer). It's the integration points with things like Hibernate, JPA, JTA, JNDI, AOP (aspectj and aopalliance), etc... that give it the most power. Any of these IOC containers can be abused by turning everything into managed beans. You use managed beans where they make sense, such as integration points between layers of your application (dao, service, ui, etc...) and where alternate implementations may be provided. Spring is a great framework, and yes, there are things that could use improvement. That being said, Rod and co are very good at listening to feedback and actually acting on it. If spring doesn't work for you, don't use it. Use what works best for your project.
  19. Re: How about this for benefits[ Go to top ]

    Matthew, for what it's worth, Guice supports @Transactional, too. You can use Spring's implementation directly (and many people do).
  20. Not really true anymore[ Go to top ]

    You can get a class automatically registered as a Spring bean using @Component -annotation, and then inject dependencies to it with @Autowired and @Resource -annotations. A suggested solution would be to configure the '100 services' in the traditional XML way (this provides ultimate flexibility and a 'directory' of services), and use annotation based configuration for the '1000 actions'. There is also a possibility of using 'Spring JavaConfig', where as the name suggests the configuration is done in Java instead of XML. However, i generally do agree with the post -- Springs dependency injection could be more elegant -- but in the end the choice once again is not about elegance, it's about business realities, and this is where Spring is really strong. Regards, Henri Karapuu
  21. completeley disagree. Spring is not invasive, its model is elegant and powerful. IoC is an important Pattern, must be understood clearly: Spring implements it in an elegant way. I think Spring configuration is not bloated, but if you like the @Annotation, take a look at SpringConfig. If you think Spring is bad, what about EJB3/2 ? For the last reason...I think it is completely wrong! For sure, if you use the SpringFramework, you must depend on spring-core.jar, that's so easy! Cannot your application live without spring? I think million of j2ee applications cannot! Otherwise, j2ee applications can live without EJB !
  22. Of course, Commercial Open Source is trying to sell you something and lock you in. What did you expect? See: http://pab-data.blogspot.com/2007/07/king-is-dead-long-live.html
  23. Come on. This must be the worst post so far this year. You can use xml, annotations, java, or construct some other configuration option using the spring api. Nothing is bloated, painful or not strongly typed if you don't want it too. But you have to know what you are doing, and why, no matter whats the name of he framework or language. If startup time is 5 or 30s for an application that I start once a year or month is really of no interest.
    I’m very sure that once we use spring lib other than spring-core.jar that means our application cannot live without spring.
    Guess what! Once you use foo.jar, your application can't live without foo.jar either... The problem is that people are using frameworks that solve complex things in a user friendly way, without having a clue about whats going on under the surface... and then blame the framework when their bad design breaks. Same thing goes with Seam or any other framework. Even though it's really easy and fast to write Hello world, you have to know whats going on, what the framework is doing so you don't have to. /Magnus
  24. Come on. This must be the worst post so far this year.
    Well, that's certainly not for a lack of competition .. ;-) Peace, Cameron Purdy Oracle Coherence: The Java Data Grid
  25. Come on. This must be the worst post so far this year.


    Well, that's certainly not for a lack of competition .. ;-)

    Peace,

    Cameron Purdy
    Oracle Coherence: The Java Data Grid
    Tee hee. There is something to this. Where have all the good bloggers gone? Seriously between this, the JEE 6 spat, and the SOAP article I might just have to cancel my subscription.
  26. If startup time is 5 or 30s for an application that I start once a year or month is really of no interest.
    Furthermore, in my experience Spring context startups tend to be slowed down by... Hibernate, the most.
  27. If startup time is 5 or 30s for an application that I start once a year or month is really of no interest.
    This is of no interest when you're starting an application. But when you're testing this SUCKS. It means it takes longer to make changes. It also takes longer to run integration tests/builds. With that said, the latest Spring 2.0.5 release includes some performance improvements , so try that out (including one I found which cuts out a lot of time if you have a lot of files - yay for me). Some general tips to making spring go faster: - Reduce the number of configuration files - Don't use classpath*:*.xml type wildcards - Reduce your number of beans - just because you can make it a doesn't mean you should. - lazy-init="true" - Turn off validation (Alternately: anyone want to rewrite Xerces?) I was profiling our app startup the other day. About 33% of the time is in Introspector.getBeanInfo() so its really not all Spring's fault IMO :-)
  28. If startup time is 5 or 30s for an application that I start once a year or month is really of no interest.


    This is of no interest when you're starting an application. But when you're testing this SUCKS. It means it takes longer to make changes. It also takes longer to run integration tests/builds.
    Sure, but most tests can be setup without spring, as plain unit test should be done. And even if you want to use spring context in your tests, AbstractSingleSpringContextTests does cache the spring context across all tests if you use the same context resource descriptors. A empty spring context is fast to start, and so is a context with not so many beans. There is no reason to start a context with all beans and dependencies wired up if you are doing testing. /Magnus
  29. If startup time is 5 or 30s for an application that I start once a year or month is really of no interest.


    This is of no interest when you're starting an application. But when you're testing this SUCKS. It means it takes longer to make changes. It also takes longer to run integration tests/builds.

    With that said, the latest Spring 2.0.5 release includes some performance improvements , so try that out (including one I found which cuts out a lot of time if you have a lot of files - yay for me).

    Some general tips to making spring go faster:
    - Reduce the number of configuration files
    - Don't use classpath*:*.xml type wildcards
    - Reduce your number of beans - just because you can make it a doesn't mean you should.
    - lazy-init="true"
    - Turn off validation (Alternately: anyone want to rewrite Xerces?)

    I was profiling our app startup the other day. About 33% of the time is in Introspector.getBeanInfo() so its really not all Spring's fault IMO :-)
    Why so many startups. Most of the time, you can use JVM hotclass replaces(at least I can) when I'm debugging and don't have to restart the app from scratch.
  30. Most of the time, you can use JVM hotclass replaces(at least I can) when I'm debugging and don't have to restart the app from scratch.
    Um... have you actually tried this? You can swap a class so long as only method bodies have changed. I hardly think tweaking a method body qualifies as "most" of the changes you're likely to make.
  31. Most of the time, you can use JVM hotclass replaces(at least I can) when I'm debugging and don't have to restart the app from scratch.


    Um... have you actually tried this? You can swap a class so long as only method bodies have changed. I hardly think tweaking a method body qualifies as "most" of the changes you're likely to make.
    Um...yes I have actually used it. I wouldn't talk about if I didn't use it and I'm well aware of its limitations. I don't tend to add many methods when I am *debugging*.
  32. Vindication![ Go to top ]

    Finally! Vindication! One person in the Java community finally agrees with me that Spring sucks. ;-)
  33. Re: Vindication![ Go to top ]

    Ah, Bill... you had to do it didn't you. I know you included the little winking smiley and all but you know this is just going to start a pro-Spring rampage.
  34. helloworld-object.xml[ Go to top ]

    http://docs.jboss.org/jbportal/v2.4/reference-guide/en/html/xmldescriptors.html
  35. Re: helloworld-object.xml[ Go to top ]

    http://docs.jboss.org/jbportal/v2.4/reference-guide/en/html/xmldescriptors.html
    JBoss Portal provides an administrative UI to configure deployments. The xml descriptors are merely there as a developer resource. Next time, do your homework before I have to chime in and make you look dumber than you normally do.
  36. Re: helloworld-object.xml[ Go to top ]

    http://docs.jboss.org/jbportal/v2.4/reference-guide/en/html/xmldescriptors.html


    JBoss Portal provides an administrative UI to configure deployments. The xml descriptors are merely there as a developer resource.

    Next time, do your homework before I have to chime in and make you look dumber than you normally do.
    Don't worry, the XML is there, and it is so awful that it screams: you may have all the tools you want, but if you needed to document it, this means that somehow one has to deal with it. Ah, and of course don't forget to stay metal, general quality of the framework will benefit, and XML will write by itself. On a more serious basis: Spring XML is not bad at all, and even if it were, there are a number of alternative ways to configure it (I prototyped a very quick way to configure a context in java in 2005, then didn't work on it anymore because it simply wasn't worth the effort: the XML config is absolutely good enough for the job, and java-based configurations tend to quickly not as structured and clean). There are now a lot of different ways to reduce the xml or avoid it altogether, but monkeys jump up everywhere and keep babbling about "how awful" the XML configuration is: they almost never show equivalent examples using other tools, and when they do they normally produce some lame near-dsl-near-natural-language simulated by using flowing constructs which in my opinion are far uglier than the clean, structured, navigable syntax the XML allows (with the help of modern IDEs such as Idea and Eclipse). So if your sport is to spot dumb people, look in that monkey camp: I'm sure you will find more palatable victims.
  37. XML wins[ Go to top ]

    I agree with you! You can try every other configuration method but you'll return on XML to configure your projects! According to me, annotations and the declarative programming is just the Chimera of modern software engineering. Embedding configuration options stucked with code is not the right solution in large projects.
  38. Re: helloworld-object.xml[ Go to top ]

    Don't worry, the XML is there, and it is so awful that it screams: you may have all the tools you want, but if you needed to document it, this means that somehow one has to deal with it.
    I agree. In my car, the motor is there, and it is so awful it screams: I may have all the wrenches I want, but if Toyota needed to document it, this means that somehow I have to deal with it. .. or I can just focus on driving while using the clever "user-interface".
  39. Re: helloworld-object.xml[ Go to top ]

    or I can just focus on driving while using the clever "user-interface".
    Which of course is what you can do with Spring ides, also. ;) By the way, I guess you have nice user interfaces for configuring things like jboss-cache, jgroups, the mbeans microkernel and things like that? It seems to me you have a fair amount of XML config, for being XML-config-bashers. And your XML config is generally far,far,far,far uglier than what is possible with Spring 2.1.
  40. Re: Bill has a friend[ Go to top ]

    Finally! Vindication! One person in the Java community finally agrees with me that Spring sucks.
    Hani always doubted you had a friend ...
  41. so what if someone agrees with you that spring sucks. EJB 3.0 isn't good either. Whatever happened to just writing a class and using servlets? Elephant in the room. You really do not need a framework even for large projects. There is just too much hype these days. Gotta read through all the marketing bullshit and hype such as "Open source", "community driven", "Enterprise level", and other shit like that which makes you want to adopt a technology.
  42. summer is officially here. This is how you know you are number 1. Someone devotes an entire, usually inaccurate post about why you suck or they won't use you. If only people devoted as much time to crafting a solution as pointing a finger. What do *I* think? How about writing something that does the job better since you have all the answers.
  43. summer is officially here. This is how you know you are number 1. Someone devotes an entire, usually inaccurate post about why you suck or they won't use you.

    If only people devoted as much time to crafting a solution as pointing a finger.

    What do *I* think? How about writing something that does the job better since you have all the answers.
    If you look at his other post, he thinks GUICE does the job better.
  44. summer is officially here. This is how you know you are number 1. Someone devotes an entire, usually inaccurate post about why you suck or they won't use you.

    If only people devoted as much time to crafting a solution as pointing a finger.

    What do *I* think? How about writing something that does the job better since you have all the answers.


    If you look at his other post, he thinks GUICE does the job better.
    Ah...so he wrote GUICE? :-)
  45. I like the quarterly xxx sucks posting. Some of them illustrate the that emperor has no clothes. Some of them let others know that there are other possible solutions out there that can do some task better than xxx can. Others elicit responses that teach the community about ways to avoid problematic situations in xxx. And yes, some of them are just plain stupid. Keep 'em coming! John Murray Sobetech
  46. summer is officially here. This is how you know you are number 1. Someone devotes an entire, usually inaccurate post about why you suck or they won't use you.

    If only people devoted as much time to crafting a solution as pointing a finger.

    What do *I* think? How about writing something that does the job better since you have all the answers.
    And just to mention: you can choose which framework (or no framework at all), it's a free world.
  47. Meh! What's with all the Spring bile? Rod is pleasant enough and Spring has done a pretty good job at cementing IoC as the design pattern of choice for the noughties. It also does a pretty good job of making a great deal of IoC unfriendly libraries behave themselves (EJB's, Struts, etc.), which is always nice. The code is well written, documented and tested. They don't break backward compatibility and their core infrastructure has been able to adapt to various advances in IoC configuration like AOP, annotations, scripting etc. Spring goes out of its way to play nice with other, sometimes more stuffy (Mr King *cough cough*) libraries. Their license is as friendly as it could be, the folks on the forum's are always helpful and the guys in charge are pretty good at not ripping into the competition at every opportunity (Mr Lee *cough cough*). So, relax and enjoy. Spring'll get faster and easier to configure, I have no doubt.
  48. the folks on the forum's are always helpful and the guys in charge are pretty good at not ripping into the competition at every opportunity (Mr Lee *cough cough*).
    When have I ripped into Spring? (excluding that one time which occurred long before Guice even existed) :)
  49. the folks on the forum's are always helpful and the guys in charge are pretty good at not ripping into the competition at every opportunity (Mr Lee *cough cough*).


    When have I ripped into Spring? (excluding that one time which occurred long before Guice even existed) :)
    Not sure, but, uhm, here? http://crazybob.org/2007/06/lies-damned-lies-and-xml.html
  50. Stink bomb[ Go to top ]

    Nothing like lighting a stink bomb before we check out for the holiday (in the U.S. anyway). I've got no problem with Arif's blog post and his opinions. He can use Guice or whatever works for his project. Spring happens to work great for us, but I am not going to argue for what Mr. Rachim should should use on his project. What I do have a problem with is the ServerSide editors allowing this non-news to be accepted on the front page. How many times do we have to tread over this issue? Do we really have to ignite this again? If Spring works for you, use it. If you want to bunk with the JBoss fellas, fine. Guice? Cool. Next topic!
  51. This is a matter of "state"[ Go to top ]

    Well, from my point of view XML configuration vs. annotations or integrating with third party libraries and having prectical and good templates is not the key point of Spring. Annotations will eventually replace XML metadata in any frameworks(indeed it already has), sparing that using XML as metadata has still its use where it is not coupled to a specific Java source file and application global such as in workflows, etc.. Having nice templates for third party libraries and frameworks is a very strong feature of Spring, and that's why I like it most. As for Ioc, I won't discuss its benefits. Especially in unit-testing. However, today, EJB3-JPA provides the same infrastructure as Spring does. So, I don't see an architectural difference there, they all depend and AOP and interception. Spring's main point is that it is a stateless framework, and application state is always kept on HttpSession. This was obviously a better strategy than EJB 2.X Stateful session beans. So Spring was the best choice of the time. Now, there's a new kid in town, Seam.. Although it is currently coupled to special technology base(JSF and EJB 3) it has a new architectural strategy. Seam puts its vote on stateful applications, and Stateful EJBs(Yes, the state can still be kept in HttpSession under the hood but the framework is completely designed to make this transparent to developer).. And, though I haven't tried seam yet in a real project, this main architectural point seems very reasonable to me... We'll see what happens in the near future, but I think seam offers a better model for the time being..
  52. There's a difference![ Go to top ]

    However, today, EJB3-JPA provides the same infrastructure as Spring does. So, I don't see an architectural difference there, they all depend and AOP and interception
    What??? You don't see an architectural difference between Spring and EJB3? Think again, please... EJB3 *is* an architecture while Spring in only a framework: With Spring you can use the architecture of your choice - with EJB3 you simply cannot. Furthermore EJB3 uses a limited form of AOP while Spring uses a full one (or more than one AOP implementation if you want) Daniele
  53. Re: There's a difference![ Go to top ]

    However, today, EJB3-JPA provides the same infrastructure as Spring does. So, I don't see an architectural difference there, they all depend and AOP and interception


    What??? You don't see an architectural difference between Spring and EJB3? Think again, please...
    EJB3 *is* an architecture while Spring in only a framework: With Spring you can use the architecture of your choice - with EJB3 you simply cannot.
    Furthermore EJB3 uses a limited form of AOP while Spring uses a full one (or more than one AOP implementation if you want)

    Daniele
    Well the borders nowadays are blurry, there are embedded ejb3 containers. EJB3 first of all is just a specification whether it has to be a container or framework does not really matter. I am personally happy the way ejb3 develops nowadayw with Seam.
  54. Re: There's a difference![ Go to top ]

    Well the borders nowadays are blurry, there are embedded ejb3 containers.
    EJB3 first of all is just a specification whether it has to be a container or framework does not really matter.
    I am personally happy the way ejb3 develops nowadayw with Seam.
    I'm sorry, but I have to disagree. Sure, EJB3 is a specification, but the EJB3 specifications force the use of an architecture where the smallest distribution unit is an object. It doesn’t matter if nowadays there are a lot of EJB3 embeddable containers: in any case you heavily depend on the EJB apis and that architecture.
  55. However, today, EJB3-JPA provides the same infrastructure as Spring does. So, I don't see an architectural difference there, they all depend and AOP and interception


    What??? You don't see an architectural difference between Spring and EJB3? Think again, please...
    EJB3 *is* an architecture while Spring in only a framework: With Spring you can use the architecture of your choice - with EJB3 you simply cannot.
    Furthermore EJB3 uses a limited form of AOP while Spring uses a full one (or more than one AOP implementation if you want)

    Daniele
    Ueh! Ti ho convertito? :)
  56. Diciamo che hai dato il... là ;-)
  57. Re: There's a difference![ Go to top ]

    Diciamo che hai dato il... là ;-)
    bello, sto thread è diventato una chat per italiani :-D
  58. For sure, the difference is well known! Anyway I cannot understand the problem: You don't like Spring? Don't use it! You like EJB3 (Oh My!) ? Good luck! I think Rod Jonhson & Al. have done a great job with Spring. Spring has been the best innovative java software of the past 5-6 years. And now there is not yet another great innovative idea below the horizon. But, of course, every thing is perfectible, and nothing is perfect. But please, do not negate the evidence: Spring framework is a milestone for j2ee smart developers, while ejb3 framework is working so hard to be wild accepted. IMHO, even if you don't like the Spring Framework, you should admit the benefit you have using it. Bye
  59. Hmm.. Yes, I do agree with you on one point.. Maybe it's because nowadays no one can clearly say what an architecute is.. On my side, I prefer to be practical and not go into deep arguements about buzzwords.. Yes, with Spring, you can use the "techonlogy, or API" of your choice.. And that is also what I specially pointed at.. One of my favorites in Spring.. Personally, I like Spring. I find it clever and use it with pleasure.. And EJB3 has learned so much from both Hibernate and Spring in the right direction, but to agree with you, with some limitations and lock in... However, my point of view from architecture was; EJB 3 bears the same philophy under mind, the lessons learned from Spring and Hibernate.. That's nothing new.. The interesting thing to be emphasized here is the conceptual difference between Seam and Spring. Or the conceptual difference between stateful and stateless "architecture" from the end user(end programmer) point of view..
  60. Re: There's a difference![ Go to top ]

    Furthermore EJB3 uses a limited form of AOP while Spring uses a full one (or more than one AOP implementation if you want)

    Daniele
    That is not true, Spring uses a subset of aspectJ and you need to allways remember that is uses proxy for AOP implementation. AspectJ or AspectWerkz are full AOP implementations. Spring and EJB3 are proxy based, that solve almost all the problems, but give you one more problem. you need to remember that they are proxy based.
  61. asphinctersayswhat?[ Go to top ]

    Wow. Thanks for that Arif. When is your book out? c:\>del /s c:\tools\spring I wondered why we weren't getting on our project -- its because we use Spring.
  62. Arif... I guest, you need "magic artifact" to make your Spring applications run with better performance.
  63. I have to say I will happily subscribe to "Spring sucks" and "I won't use it". This however has nothing to do with Spring-the-framework. As usual it's the people who wreck it. In my view Spring has significantly lowered the bar for skills. Many people who have embraced Spring did that for the only reason that they never understood or bothered to understand other technologies/frameworks (including EJB). The general style usually used to introduce Spring - EJB sucks so use Spring - doesn't in fact do good service to Spring. People take Spring and then start piling up same old sh*$# only in the "Spring way". I, personally, am most frustrated at places where EJB-based implementations, terribly implemented but actually working are being replaced by Spring ones, just for the sake of following the trend.
  64. As usual it's the people who wreck it. In my view Spring has significantly lowered the bar for skills.
    As did Java (vs C). And C (vs Assembly).
  65. ...In my view Spring has significantly lowered the bar for skills....
    that's a good point, not a bad one ! would you prefer that the j2ee stack remains just for the very best people ????
    ...Many people who have embraced Spring did that for the only reason that they never understood or bothered to understand other technologies/frameworks (including EJB)....
    i don't think so. i have been using the "standard" j2ee stack for years before switching to spring and i can say that, in order to use spring, you still need to understand in depth what is happening under the cover when you use a spring helper. do you really think that being able to write some copy&paste boilerplate code (for jndi lookup, for db connection, for example) gives you so much more understanding ?
  66. Funnily while seemingly disagreeing with me you are in fact re-enforcing the exact points I made. You say with Spring "you still need to understand in depth what is happening under the cover". Exactly, and those who do - benefit and deliver. I am more than sure that these people would have done well with "standard" j2ee stack. Unfortunately from my experience "many people who have embraced Spring" do not understand. With the "standard" stack they would have evolved - either learned or failed and disappeared into oblivion. With Spring - they linger on longer. Yes, I want the very best people to use J2EE stack. Dumbing the technology down (and I mean this in an abstract context, not Spring one) scores extremely low on my list of values.
  67. Another issue is that of the Golden Hammer problem - When the hammer is the only tool that you have, every problem seems like a nail. I see a lot of projects starting small with very valid reasons of using Spring. But then the infection manifests - every one starts using Spring every where without evaluating if they NEED Dependency Injection in the first place. Reminds me of the long forgotten article by Martin Fowler - http://www.martinfowler.com/articles/injection.html Service Locator is not something which is not out of fashion. IMO it saves a lot of that dependency configuration stuff in the first place. Regards, Mrinal
  68. Old Wine In New Bottles[ Go to top ]

    I think the comparison is nothing but Old wine in New Bottles and yes Spring has outlived all these hollow comparisons. Thanks, Franklin
  69. Spring critics[ Go to top ]

    I have yet to meet one single developer who actually used Spring in a real project, coming back and telling me that Spring "sucks" (anybody in this thread? that would be a first). All the Spring critics I've seen so far, are people telling us they won't use the framework, without having fully investigated the whole thing. Like Mr Rachim. For example, the constant moaning about the "XML-hell" aspect of the framework has been addressed many, many times. Short answer is : there are other alternatives to XML configuration in Spring. Maybe it's too much to ask, but people would do themselves and others who might read them, a favor by refraining from writing about subjects they haven't fully researched. Just some thoughts.
  70. Re: Spring critics[ Go to top ]

    there are other alternatives to XML configuration in Spring.
    While this is true, I tend to go farther and directly state that Spring XML config does not suck AT ALL: not only it is a clear - and structured - way for expressing what it does need to express (a structure), but also it offers a number of features allowing reuse of definitions through composition or inheritance, modularization by means of context separation (direct imports or xml context aggregation), syntetic definitions through tag handlers which may be considered a way to impose "sensible defaults" which may be overridden by reverting to normal bean configurations, etc.etc.etc. With the support offered by modern tools such as Eclipse SpringIDE or IDEA we now have refactoring capabilities, cross-searches of usages, navigation features, various analysis, and so on, bringing a nice, simple, consistent tool to an almost perfect state for what it does need to do. Isn't this some sort of "duplication", given the fact that a java configuration system automatically gives all of this? Maybe, but I think that the structure that the XML naturally induces is not bad at all, for a configuration system: I experimented with various styles of java configuration and wasn't particularly attracted by any of them. More than that: I never really feel the need of anything more than what I have with Spring. This is why I tend to get irritated when I read that "Spring sucks" or "Spring API is not usable": this is simply not true at all. It may MAYBE made better, but there surely isn't any positive revolution on the horizon, yet. Assimilating the "Spring vs Guice" comparison to the "Struts/EJB2 vs all-the-nice-things that came after" one is surely a good marketing try, but is completely off-target: Spring is not Struts 1, nor EJB2, and moreover Spring IS a lot of those "nice-things-that-came-after". Prove your value, then have the world recognize your value, then you will be able to say that "Spring sucked". Up until now, I only see annotation configuration, more dependencies and invasiveness, and unstructured java configurations in a quasi-descriptive language which do not give value at all to solve the hardest problems we are facing these days (GWT does, in a smart way, for instace: this is real innovation). In short, what is important for a tool such as Spring XML configuration is that it offers a clear, simple, and powerful set of tools to enforce best practices, and to obtain nicely organized structures of modules (application contexts). Having said that, if a team does NOT use those tools, this surely as hell means there will be a lot of incredibly dumb and verbose XML: but I think there is not a single tool in the world that prevents idiotic use or abuse.
  71. Re: Spring critics[ Go to top ]

    Well said. I also tire of the "XX sucks" crowd when they're talking about things that work. They're people who think that crowing loud or going against the grain FOR ITS OWN SAKE is somehow noble. "Stop drinking the koolaid" is a big thing you'll hear out of them, even when you're being perfectly reasonable about why you support something, because it gives them a thrill to be some kind of iconoclast, and implicitly superior to the poor huddled masses. Sorry to get psychological, but this kind of flamebaiting of Spring is tired. You know why people said "EJB2 sucks" or "Struts sucks"? Because they did. There were lots of tiresome problems with them that got in the way of actual productivity and didn't make sense. At the time Spring was created, you could point to it as an alternative to Spring not because it was just different, but because it grew directly out of experiences with EJB2 and other technologies. There were specific pain points that were addressed. It became popular on its own merit, not simply because it was the big new thing (I'm looking at you, ROR). Is there room for improvement? Sure, as there is with anything. But just hopping on a "Spring sucks" bandwagon without really understanding why (maybe you just didn't "get it", though there isn't much to get; maybe you are a natural contrarian; maybe you have a vested interest in Spring not succeeding so that your product does **cough jboss cough**) or ADMITTING why is just poor form. Man, why do I find myself missing the days when I could contribute something to this board other than a fed up blast of these flamebait posts? back in the day there was actual useful discourse here. Now there's so much noise that I only find it worthwhile to contribute when I get really angry by stupid flames. Sigh....
  72. Re: Spring critics[ Go to top ]

    In addition to the general XML sucks complaints about Spring, it seems those vested in some competing containers have issue with Spring. That fact that Spring can contain or be contained makes it flexible, integratable and hard to compete against. It's like a Java VM on a Windows OS, MS can't kill it. IoC is a great pattern that people should be using whether the implementation is homegrown, Spring or something Guicier. Currently, Spring hits a sweet spot and gives many a face-saving, bloodless path and argument out of EJB-think. As for XML, Spring provides multiple strategies to wire your system so the XML argument seems like noise. Despite this looking like a stupid TSS post it's good to test the argument of even realy good technologies now and then.
  73. Well, I've been hearing great news about spring though I have never had a chance to work with it until recently when I wanted to evaluate. I did not understand why the MVC configuration itself has to be that complicated. I felt, struts did a good job at it. When it comes to the bean configuration, i feel XML based configuration makes is more clumsy. Also, the option of combining it with unit test configuration makes it more and more difficult. But my basic question is, such bean configuration being something that get rolled off to production environment who would on the world would like to keep the unit testing configuration as well in it. I felt it's so stupid (I am sure there must be a way around to get rid of unit-test configurations when it gets rolled into production). If you have had some experience with ATG, you would agree with me that how elegant such bean (atg components) configurations are - what spring achives in the name of IoC is what done in ATG world as well. AFAIK about spring MVC, in my opinion, is not living up to it's braggings. I also felt, I would love to spring to develop my lab projects for fun or something. Spring framework is still in my list as potential framework to migrate our enterprise applications though. -- panfox
  74. To my experience, Arif is very right. Period! We have used Spring and Dependency Injection in a large project, and the result is ugly. You end up with tons of configuration files, and increase the complexity of the project. I have experienced countless hours wasted figuring out misconfiguration in a Spring configuration file. Annotation approach is definitely a step in the right direction. Dependency Injection itself is not a bad idea, if it is used carefully and when appopriate. The current trend is that developers simply turn every single Java class into a Spring service. More specifically, every class is turned into a set of getters and setters. The latter simply breaks the object oriented design principles. Classes must have clear and precise interfaces. A lot of getters and setters is simply a bad idea!
  75. To my experience, Arif is very right. Period!

    We have used Spring and Dependency Injection in a large project, and the result is ugly. You end up with tons of configuration files, and increase the complexity of the project. I have experienced countless hours wasted figuring out misconfiguration in a Spring configuration file. Annotation approach is definitely a step in the right direction.

    Dependency Injection itself is not a bad idea, if it is used carefully and when appopriate. The current trend is that developers simply turn every single Java class into a Spring service. More specifically, every class is turned into a set of getters and setters. The latter simply breaks the object oriented design principles. Classes must have clear and precise interfaces. A lot of getters and setters is simply a bad idea!
    And exactly how is Spring forcing you to use setters and getters? You run a large project without well defined design rules of what should become a spring bean, how to use setters and getters etc, and then you blame Spring for failing? /Magnus
  76. To my experience, Arif is very right. Period!

    We have used Spring and Dependency Injection in a large project, and the result is ugly. You end up with tons of configuration files, and increase the complexity of the project. I have experienced countless hours wasted figuring out misconfiguration in a Spring configuration file. Annotation approach is definitely a step in the right direction.

    Dependency Injection itself is not a bad idea, if it is used carefully and when appopriate. The current trend is that developers simply turn every single Java class into a Spring service. More specifically, every class is turned into a set of getters and setters. The latter simply breaks the object oriented design principles. Classes must have clear and precise interfaces. A lot of getters and setters is simply a bad idea!
    Don't blame the tool, blame the user and speak for yourself. You used Spring inappropriately and you turned every class into a service. Just because you cannot drive and wrecked your car doesn't mean the car is a poor invention. Perhaps you need to pass the road test instead of just getting behind the wheel.
  77. "Don't blame the tool, blame the user and speak for yourself. You used Spring inappropriately and you turned every class into a service." You obviously did not read my text. I said: "Dependency Injection itself is not a bad idea, if it is used carefully and when appopriate". And then I said: "The current trend" I would personally never make every class to a Spring service, but that is what was done by several experienced Java developers. Just that you have learnt Spring, it does not necessarily qualify you to be a good driver.
  78. "Don't blame the tool, blame the user and speak for yourself. You used Spring inappropriately and you turned every class into a service."

    You obviously did not read my text. I said: "Dependency Injection itself is not a bad idea, if it is used carefully and when appopriate". And then I said: "The current trend"

    I would personally never make every class to a Spring service, but that is what was done by several experienced Java developers.

    Just that you have learnt Spring, it does not necessarily qualify you to be a good driver.
    Oh, I read your text "We have used Spring and Dependency Injection in a large project, and the result is ugly. You end up with tons of configuration files, and increase the complexity of the project. I have experienced countless hours wasted figuring out misconfiguration in a Spring configuration file. Annotation approach is definitely a step in the right direction." *You* ended up with an ugly result. *You* spend countless hours figuring out a problem most likely caused by your ugly result. If your result was ugly, the most likely cause was you and your inappropriate use of Spring. Ayou've shown, learning it doesn't qualify you to be a good driver. *Your* developers made mistakes and you are blaming the tool. Don't blame the car for the drivers inexperience.
  79. Oh, I read your text

    "We have used Spring and Dependency Injection in a large project, and the result is ugly. You end up with tons of configuration files, and increase the complexity of the project. I have experienced countless hours wasted figuring out misconfiguration in a Spring configuration file. Annotation approach is definitely a step in the right direction."

    *You* ended up with an ugly result.
    *You* spend countless hours figuring out a problem most likely caused by your ugly result.

    If your result was ugly, the most likely cause was you and your inappropriate use of Spring. Ayou've shown, learning it doesn't qualify you to be a good driver.

    *Your* developers made mistakes and you are blaming the tool.

    Don't blame the car for the drivers inexperience.
    Spring and DI does not make nothing ugly, the only problem is the big configuration files in big projects, but since the time I started the Spring-Annotations project, you can reduce a lot this configuration size. and now it is being implemented a similar feature in the core of the spring-framework, what will make it easy for any one to use. but I have to agree, big XML configuration files are difficult to read and maintain, but you can always break it into smaller modules.
  80. "Don't blame the tool, blame the user and speak for yourself. You used Spring inappropriately and you turned every class into a service."

    You obviously did not read my text. I said: "Dependency Injection itself is not a bad idea, if it is used carefully and when appopriate". And then I said: "The current trend"

    I would personally never make every class to a Spring service, but that is what was done by several experienced Java developers.

    Just that you have learnt Spring, it does not necessarily qualify you to be a good driver.
    They skip OO programing and leapfrog right into SOA, the promising land.
  81. Five reasons for not choosing for Spring is not a lot. Based on my personal experience I can find many more reasons for all the other frameworks out there for not using them, starting with EJB3 Session Beans. So the question is: what's the better alternative? I'm using Spring already for years - in small and big projects - and it simply works for me.
  82. To my experience, Arif is very right. Period!

    We have used Spring and Dependency Injection in a large project, and the result is ugly. You end up with tons of configuration files, and increase the complexity of the project. I have experienced countless hours wasted figuring out misconfiguration in a Spring configuration file. Annotation approach is definitely a step in the right direction.

    Dependency Injection itself is not a bad idea, if it is used carefully and when appopriate. The current trend is that developers simply turn every single Java class into a Spring service. More specifically, every class is turned into a set of getters and setters. The latter simply breaks the object oriented design principles. Classes must have clear and precise interfaces. A lot of getters and setters is simply a bad idea!


    Don't blame the tool, blame the user and speak for yourself. You used Spring inappropriately and you turned every class into a service.

    Just because you cannot drive and wrecked your car doesn't mean the car is a poor invention. Perhaps you need to pass the road test instead of just getting behind the wheel.
    I second this opinion i have used spring in about half a dozend projects by now, and turning every class into a service is the worst decision you can make. I personally made the best experiences with IOC if used on a rather high level as binding glue between the layers. Which means, view layer -> spring beans, bo -> spring beans -> dao spring beans, but nothing else except maybe some aop constructs which are bound to the layer beans. Everything else in between is hard linked. That way you only have to touch the configuration ocasionally it does not become overly bloated but you still can work with simulated layer objects etc... all the stuff which IoC can help you with. Spring is a hammer, that does not mean you can repair everything with it.
  83. To my experience, Arif is very right. Period!

    We have used Spring and Dependency Injection in a large project, and the result is ugly. You end up with tons of configuration files, and increase the complexity of the project. I have experienced countless hours wasted figuring out misconfiguration in a Spring configuration file. Annotation approach is definitely a step in the right direction.

    Dependency Injection itself is not a bad idea, if it is used carefully and when appopriate. The current trend is that developers simply turn every single Java class into a Spring service. More specifically, every class is turned into a set of getters and setters. The latter simply breaks the object oriented design principles. Classes must have clear and precise interfaces. A lot of getters and setters is simply a bad idea!
    Of course, when I was saying that I've never met an actual Spring user complain about the framework, I was referring to people who have a minimum set of skills as of application design... I do realize that the above comment appears as inflammatory, but, since I have zero tolerance for programmers who can't program, take it anyway you want it.
  84. DI[ Go to top ]

    I think DI can be separated on 2 parts: 1. Hard dependency. Between objects that will not be modified in future( static dependency ) For this type we using Java config classes and annotation in code for clearness. 2. Soft dependency. Changeable part of dependencies(dynamic). We use this for replace dependency externally ( replace real service with mock for example , change property value from one property to another for example). Combining these two complementary parts we can build great applications IMHO. Spring contains all of these.And I like it, because for big applications I can combine both of these and for small choose only one preferrable at this moment. Just my 2 cents. Thanks Spring Developers for Great Integration Framework. p.s. Sorry for bad english.
  85. congig sucks[ Go to top ]

    xml configuration realii sucks, jYog.com
  86. Re: jyog sucks[ Go to top ]

    xml configuration realii sucks,
    Your level of spelling and level of intelligence has really been demonstrated by that post. Congratulations
  87. Re: jyog sucks[ Go to top ]

    I think that u r a school boy, who comes here to learn spellings.
  88. As some has already mentioned xml configuration is not the only way to use spring. Annotation and Java configuration classes are available. To be honest there isn't a problem with using xml configuration as long as you plan/design it properly. It's really getting old news now for not using Spring because of xml configuration. Spring allows easier J2EE/Java EE development with new features/sub-projects soon to be available. I cannot see why some people are so against using Spring....finally have we not had this debate quite a few times already?!
  89. Arif doesn't know what he's talking about.
  90. Just one last post. I think all the reasons are valid, but there are a lot of reasons for "why to use spring" too. nowadays you do not need to write all your configuration using XML, you have Spring Java Config, @Component and @Autowire, and http://sannotations.sourceforge.net project as alternatives. if you want a scripting language, you have Groovy SpringBuilder. and I think that the main thing about this post is that "there is no silver bullet". Spring is a great framework for lots of situations. I use it for years. but I think that there are situations where it does not fit. one of the responsibilities I have as an architect is to analyze each project, and tell what is the best technology, framework, language, combination of ..., for the project. Most of the projects I have used java. almost all java projects I used spring. but some projects did not used java. and some java projects did not used spring. yes, spring is great, java is great, but you do not have to embrace a technology or a framework and use it all the time, you need to analyze every situation and choose what is best for that situation and that client. well, at least this is my opinion.