Discussions

News: Ten Common Misconceptions about Spring

  1. Ten Common Misconceptions about Spring (57 messages)

    Steve Anglin posted an article on OnJava called "Ten Common Misconceptions about Spring," addressing some of the criticism some have leveled against the popular framework. The criticisms are:
    1. Spring is not lightweight. It aims to do everything and is becoming fat and bloated.
    2. Spring is overkill for simple applications.
    3. Spring does not scale to handle very large applications.
    4. Spring forces you to use Aspect-Oriented Programming (AOP) which is experimental.
    5. Spring replaces Java Enterprise Edition (JEE).
    6. Spring and EJB are mutually exclusive.
    7. Spring cannot take advantage of Java 5 annotations like EJB3 does.
    8. For a large application, Spring’s XML can become a maintenance nightmare.
    9. Spring does everything with reflection, so it is slow.
    10. Spring MVC is complex and not as simple as the rest of Spring.
    Some of the criticisms are obviously offbase for anyone familiar with Spring, but others have some legitimate basis (for example, the point about reflection is very valid: the entry mentions that if you're using 1.3, reflection is very slow, but 1.4 sped it up by 2000%. Unfortunately, even 1.4's reflection is slow, so the best suggestion is still to test for speed to see if your code runs fast enough, and if it doesn't, find something that helps it run faster.) What do you think of the list? Have you any criticisms to add, or have you found other similar generally misled perceptions?

    Threaded Messages (57)

  2. These are not misconceptions, but opinions based upon experiences. I'm surprised this is not general developer public knowledge.
  3. Well, that's a fair comment - but I'd say that such experiences were based on misunderstandings or misuse, in most cases.
  4. Some thoughts[ Go to top ]

    As a caveat to these points, they all take spring 2.0 into consideration. 1. Have you looked at the distribution? Notice the module breakup (which is more prevalent in spring 2.0) 4. AOP is far from experimental at this point, as there are well established implementations (such as AspectJ). In any case, the spring-aop module is not required, and you're not forced to use it unless you want true pointcuts and advice (ProxyFactoryBean != AOP, it's simply a standard use of java.lang.reflect.Proxy) 7. This is not true. I use annotations for declaring my transaction semantics, pointcuts, validations and auditing semantics. Granted, some of this is custom code, since only my app knows what some of these annotations mean. It just so happens that spring doesn't come with many built in annotations, because it uses the standard ones like the jpa and ejb ones. But that doesn't mean it doesn't take advantage of them. 8. I point to the ejb-jar.xml, toplink-ejb-jar.xml, application.xml, orion-application.xml and leave it at that. 9. Reflection performance is quite good in 1.4+. This is mostly an issue if you're using dynamic proxies, as dependency injection is really done only once upon instantiation (assuming you have singleton beans). This is more of a consideration when using dynamic proxies and AOP. 10. This is a personal preference, use another MVC framework if you like, and you can still integrate spring as your IOC container (it comes with integration for several already). As a side note, our code has very few places which ever reference spring. To me, that's what lightweight means. 1. Dao classes. 2. Small amounts of glue code. 3. The web.xml file.
  5. Bad link[ Go to top ]

    Steve Anglin posted an article on OnJava called "Ten Common Misconceptions about Spring,"
    The link is bad - it links back to this thread.
  6. Re: Bad link[ Go to top ]

    My apologies. The link has been fixed.
  7. I agree. But then again... 1.) EJB is not lightweight either. 2.) EJB is also overkill for simple applications 3.) EJB also does not scale well if developers have moderate to little experience with EJB. (which has been my experience at MANY companies) 4.) Many EJB containers, like JBoss, are heading down aspect centered containers. 5.) Um, no. Read #6 6.) Spring does not replace EJB. In fact, there are several connector classes available that allow you to use EJB with Spring - designed specifically for integration - and not just for legacy stuff. 7.) Donno. 8.) Yes. So can any XML mapping construct like Hibernate. If you use Spring Annotations, no difference between Spring and EJB with annotations. 9.) Reflection is not slow. Maybe in the old days it was, but not know. What about EJB with annotations? 10.) EJB3 can be very complex as well. There are pros and cons to any framework that attempts to be the end-all to everything. Spring is nice, so is EJB3. But I have to admit, the battle in the future is not EJB vs. Spring, its Java vs. Ruby and dynamic languages. My Two Cents, Mark drop.com
  8. .. Spring is nice, so is EJB3.
    Huh? EJB3 is the same as EJB2 with the exception of Entity Beans. Spring cannot be compared with Entity Beans.
  9. Huh? No it isn't. Session beans are much simplified too, and are just a specialised/formalised instance of spring beans. Want proof? Pitchfork. That project shows that Spring can trivially implement large swathes of the non-persistence bits of ejb3, and have them function just as session beans would in a container.
  10. EJB3 is the same as EJB2 with the exception of Entity Beans.
    Ugh...this statement is just plain wrong. Have you really taken a look at EJB3?
  11. EJB3 is the same as EJB2 with the exception of Entity Beans.

    Ugh...this statement is just plain wrong. Have you really taken a look at EJB3?
    XDoclet used to provide me with functionality that now is available via annotations for lucky souls using Java 5 :) Please tell me exactly how Session Beans in EJB3 are that much different from earlier session beans? MDB differences?
  12. Differences...[ Go to top ]

    - Session bean implements your business interface - Dependency injection (examples: persistencemanager, other ejb) - Interceptors (using annotations) - Transaction configuration using annotations MDBs are not much different. Well, they are easier to configure (did I mention annotations?). And you again get the dependency injection to other session beans, dependency injections, etc. Maybe not enough differences, but hey, in the end its all just java anyway (spring, ejb, ...)
  13. Another spring misconception?[ Go to top ]

    I have been hearing and reading about spring being the de facto framework for developing simple web applications. So spring does not work well with complex web applications?
  14. Defacto standard!!! No such thing in the web space anymore.
  15. But thats not FUD, thats common sense. ie Spring needs training (or at least the abaility to read and a couple of days), as does anything else. Is it the best choice for your projects really depends on many many variables. To say that it is always the correct choice is as wrong minded as to say it is always the wrong choice. To mention FUD and black ops PR within this discussion is just about your religion this year. i.e. your own perspective vs theirs. Jonathan ps The way I 'trained' was to do it myself: http://www.microspring.org/ - it's a bit out of date now :)
  16. 11th opinion[ Go to top ]

    Just my 2 cents. I only had one major issue with Spring, and it's the same I have with many open source tools. The examples of use and/or advantages aren't clear when just glazing over the information. My fault for not digging deeper of course, but still, I always want to know first whether or not I would be interested in a framework. From the bit of digging I did do, it looks like a very valuable assest. I think the lack of understanding within 60 seconds of looking at the web site is hurting Spring more than anything else.
  17. Re: 11th opinion[ Go to top ]

    Just my 2 cents.

    I only had one major issue with Spring, and it's the same I have with many open source tools. The examples of use and/or advantages aren't clear when just glazing over the information.

    My fault for not digging deeper of course, but still, I always want to know first whether or not I would be interested in a framework. From the bit of digging I did do, it looks like a very valuable assest.

    I think the lack of understanding within 60 seconds of looking at the web site is hurting Spring more than anything else.
    I read Rod's book about the concepts in Spring, so I was pretty much in when I read that Spring was in development. What I tend to do is point people to the Introduction to the Spring Framework paper host on this site. IMO, if you read that article and DON'T find what it says useful, Spring is probably not the tool for you(figurative you, not you Leif).
  18. I guess I was expecting the "article" to be more than a reposting of marketing material from I21's website. He could have just posted a URL to the website instead. :) Some of the responses are interesting though.
  19. 1, 2, 3 and 8 are true[ Go to top ]

    1, 2, 3 and 8 are true, at least in 1.xx versions. Hopefuly Spring 2.0 solves some of the issues.
  20. Re: 1, 2, 3 and 8 are true[ Go to top ]

    1, 2, 3 and 8 are true, at least in 1.xx versions.

    Hopefuly Spring 2.0 solves some of the issues.
    I'm talking about Spring configuration here, not the rest of the framework. If Spring has a publicity issue it is because it is really several frameworks bundled into one. It's fair to argue the merits of each sub-framework but not really fair to say Spring in general stinks because you don't like Spring MVC for some reason. #8 Config file complexity Spring configuration allows you to chunk up the config xml into any number of files. This gives more power to your project toward coming up with a sane way to handle a "large" project configuration. Large projects bring complexity to everything on their own so it is hard to blame Spring for that growth. At least Spring is flexible enough to allow your team to decide how to chunk it up. There is the possibility that too much is being configured within Spring on a given project. I've seen Spring config abused as the "only" factory in a project. I've also seen many lines of configuration that could be simplified into one block. Maybe #8 would be a fair argument if one could demonstrate a large code base where everything else is laid out and packaged crisp and clean and the only remaining issue is that darn Spring config file. RE: Spring 2.0, I think helps a bit in having better defaults. Shoot, I don't know exactly how to express it but the examples I've seen show that you need fewer lines of Spring config code to config many of the built-in beans. ______________ George Coller DevilElephant
  21. I always found it rather ironic that after Rod Johnsons excellent book which took apart EJB pretty comprehensively (thank god), he went ahead a build a framework so large that it now suffers many of issues he identified with EJB. The building of SpringMVC was particularly perplexing, as WebWork provided a valid alternative Action/Command pattern framework to Struts. To me it seemed to be a "not invented here" issue. regards Malcolm Edgar http://click.sourceforge.net
  22. I think it is a common phenomenon. Someone invents something smart. Simple and powerful. It becomes a huge success. But all the users want feature 1, feature 2, ..., feature 1 million. And suddenly it is huge and not simple any more.
  23. I think it is a common phenomenon.

    Someone invents something smart. Simple and powerful.

    It becomes a huge success.

    But all the users want feature 1, feature 2, ..., feature 1 million.

    And suddenly it is huge and not simple any more.
    It doesn't have to be like that though. If a framework layers well enough, it can be huge but still simple for the common cases. It is a common misconception of people to think that huge == complex. I don't think Spring is anymore difficult to use than it was when it started out. It simply has 'answers' now that you would otherwise solve using another framework (which btw is not necessarily a good thing).
  24. I think it is a common phenomenon.

    Someone invents something smart. Simple and powerful.

    It becomes a huge success.

    But all the users want feature 1, feature 2, ..., feature 1 million.

    And suddenly it is huge and not simple any more.


    It doesn't have to be like that though. If a framework layers well enough, it can be huge but still simple for the common cases. It is a common misconception of people to think that huge == complex. I don't think Spring is anymore difficult to use than it was when it started out. It simply has 'answers' now that you would otherwise solve using another framework (which btw is not necessarily a good thing).
    Absolutely. How has the inclusion of say Toplink supported affected me, someone who uses Hibernate? The Spring guys have done an exception job of enhancing Spring while keeping it easy to use.
  25. Is it black PR ?[ Go to top ]

    All except point 8 are false. Question is: which company paied Joseph for this article or he's just an ignorant ?
  26. Re: Is it black PR ?[ Go to top ]

    All except point 8 are false. Question is: which company paied Joseph for this article or he's just an ignorant ?
    Jaroslaw, if you read the newspost - including the title, which has a decent summary - you'll see that it's "ten misconceptions about Spring" and not "ten flaws of Spring." I've used Spring in anger. I'm well-aware of what I think its flaws are, and what I think its strengths are. The news post doesn't include my opinion; it's a summary of the article posted on OnJava.com, which is very much a defense of Spring against these misconceptions, and I entirely agree with the article, for the record.
  27. Re[ Go to top ]

    Sory Joseph, my fault, I haven't read te article, only your post, that's true that this article defends Spring. I'm an ignorant ;-)
  28. Come on! The critisms about Spring are completely wrong way. I have been on a J2EE Design Pattern training course and the instructor who has been in the industry even before i was walking around in my nappy stated that EJBs are not the way forward anymore. Spring offers all the benefits of EJB technology and more. Spring is totally not heavyweight anybody who thinks this hasn't read enough about Spring. I recommend that people read Spring throughly and implement Spring in their applications before making silly statements about Spring. Enterprise application development is more than EJBs ...you can build scalable, maintainable and highly performant enterprise apps without EJBs. Spring is a Java/J2EE application framework that assists developers in developing such applications. AOP is experimental?!!! Come on...
  29. Misconcieved criticism[ Go to top ]

    The whole of the spring distribution is large. That does not stop or affect the fact that spring is light weight. If you only use the IOC thats all that will be loaded into memory thats how java works. Spring is especially good for simple applications. I have written applications that scale to the largest developments and greatest thoughputs developed in the UK recently using spring no problem. Spring does not enforce AOP we use spring but do not use AOP in production code. Why on earth would spring and EJB be mutually exclusive. Spring cannot take advantage of many other things that are not really relevent to it too. Spring can be a maintenance problem if not implemented thoughtfully as can all implementations. If spring is a performance problem you are probably using it at the wrong granularity. Who cares about spring MVC cheers Robert
  30. Re: Misconcieved criticism[ Go to top ]

    The whole of the spring distribution is large. That does not stop or affect the fact that spring is light weight. If you only use the IOC thats all that will be loaded into memory thats how java works.
    What I find amusing is that this statement also applies to JavaEE app servers, which the Spring folks have historically derided with "heavyweight", "don't make me eat the elephant", etc. It seems the criterion should apply equally to both.
  31. Re: Misconcieved criticism[ Go to top ]

    The whole of the spring distribution is large. That does not stop or affect the fact that spring is light weight. If you only use the IOC thats all that will be loaded into memory thats how java works.

    What I find amusing is that this statement also applies to JavaEE app servers, which the Spring folks have historically derided with "heavyweight", "don't make me eat the elephant", etc. It seems the criterion should apply equally to both.
    This is exactly the kind of FUD that gets spread about Spring. Read the article and look at point #5 carefully - "Spring is largely about JEE integration". The first two Spring books do argue that EJBs are overused, but they also plainly state when EJBs are a very good solution for a problem. Spring provides support for implementing and accessing EJBs, and it provides support for using many other JEE APIs, as stated in the article. Try sticking to facts instead of baseless claims that use expressions like "the Spring folks", which could refer to anyone.
  32. Re: Misconcieved criticism[ Go to top ]

    Spring does have a learning curve. And a large established spring project using aop, annotations, plus an assortment of ad hoc open source technologies, and the spring transactions with annotations and execution blocks mixed in, and 20 odd config files, all including each other, with wiring and config mixed together, and jmx support, bundled with some random soap server etc etc. Well, it's a pretty huge elephant. Joining such a project is a very big learning curve, to say otherwise is wrong. Now spriong may only be 30% of that BUT it encourages this type of architecture. i.e. aspects hiding logic, config bloat, inclusion of lots of open source. So, I wouldn't say it's FUD, more an observation from someone at the bottom of the learning curve, while you are perched at the top saying it's easy, come on, start climbing. Jonathan
  33. To Spring or Not...[ Go to top ]

    Spring does have a learning curve. And a large established spring project using aop, annotations, plus an assortment of ad hoc open source technologies, and the spring transactions with annotations and execution blocks mixed in, and 20 odd config files, all including each other, with wiring and config mixed together, and jmx support, bundled with some random soap server etc etc.

    Well, it's a pretty huge elephant. Joining such a project is a very big learning curve, to say otherwise is wrong. Now spriong may only be 30% of that BUT it encourages this type of architecture. i.e. aspects hiding logic, config bloat, inclusion of lots of open source.

    So, I wouldn't say it's FUD, more an observation from someone at the bottom of the learning curve, while you are perched at the top saying it's easy, come on, start climbing.

    Jonathan
    I agree Spring does have a learning curve... But so does everything new ???? Either a project commits to a chosen framework or does not... Commitment to the framework mean getting the developers upto speed on how to use it... Send them on courses or allocate learning, book reading time... The FACT is at least this learning is possible... indpendently of the project you are working on... I have come into projects that have written their own frameworks (scaffolding code)... This has NO courses to learn it, NO books and No documentation... So which LEARNING CURVE would you choose ???? Plus from my perspective once i leave that company that knowledge of the inhouse framework is useless and throwaway... At least any Spring knowledge is transferable... The FUD from people comes from... There are 100's of java frameworks available each probably claiming to best the best... So to a novice Spring is just another one... So the FUD is about wether it is the right choice to commit to learning spring or not...
  34. Re: Misconcieved criticism[ Go to top ]

    Spring does have a learning curve. And a large established spring project using aop, annotations, plus an assortment of ad hoc open source technologies, and the spring transactions with annotations and execution blocks mixed in, and 20 odd config files, all including each other, with wiring and config mixed together, and jmx support, bundled with some random soap server etc etc.

    Well, it's a pretty huge elephant. Joining such a project is a very big learning curve, to say otherwise is wrong. Now spriong may only be 30% of that BUT it encourages this type of architecture. i.e. aspects hiding logic, config bloat, inclusion of lots of open source.

    So, I wouldn't say it's FUD, more an observation from someone at the bottom of the learning curve, while you are perched at the top saying it's easy, come on, start climbing.

    Jonathan
    I disagree. In fact, I would say that the learning is much, much smaller than you would think. I've worked with serveral projects and people ranging from very junior to experienced senior and even the junior people have been very productive BECAUSE of the consistency that Spring introduces. For example, we use AOP for security, profiling, exception handling, transactions, and caching. The resulting business logic is very clean, clear, and tight. People can proceed to make business logic changes without screwing up say caching. People can make security changes without messing up business logic or profiling. Hibernate is much easier(and it wasn't hard) to pick up because session management is pulled out of the equation. Spring is much easier than dealing with someone's custom factory, database tier, and custom infrastructure.
  35. Re: Misconcieved criticism[ Go to top ]

    Spring is much easier than dealing with someone's custom factory, database tier, and custom infrastructure.
    Err,spring uses springs custom factory, database tier and custom infrastructure. If you don't know spring its exactly the same as learning any custom etc. etc. i.e. it's only simple for you because you know it already. Just as someone else who nkows another infrastructure will tell you its simple and spring is hard because they don't know it. Yes, spring is currently in fashion, and yes it's better than most in-house frameworks. But it's still one implementation and there will be other things along that are in some way or other better. Probably are at the moment, but I'm using Spring/or no framework at all. Jonathan
  36. Re: Misconcieved criticism[ Go to top ]

    Spring is much easier than dealing with someone's custom factory, database tier, and custom infrastructure.


    Err,spring uses springs custom factory, database tier and custom infrastructure. If you don't know spring its exactly the same as learning any custom etc. etc. i.e. it's only simple for you because you know it already. Just as someone else who nkows another infrastructure will tell you its simple and spring is hard because they don't know it.

    Yes, spring is currently in fashion, and yes it's better than most in-house frameworks. But it's still one implementation and there will be other things along that are in some way or other better. Probably are at the moment, but I'm using Spring/or no framework at all.

    Jonathan
    Please tell me you are kidding. I wasn't born know Spring. I used the resources available to learn it. And there are FAR more resources available for Spring than any in-house framework. I've worked at several companies, large and small. From large telecome and wireless to credit card and I've interacted with others like large insurance company and without fail I've found that internal documentation sucks. These in-house frameworks depend in institutional knowledge to keep them going. Why? Beause the say, insurance company is just that. IT supports there core so guess how much time they devote to documenting things. Instead, they depend on people who are there to pass information to the newbies. And when those people leave, forget about it. If I had a choice between using say your custom factory and Spring's I'll take Spring. If the choice, for new development is between my custom factory and Spring's, I'll take Spring. In fact, I had this very conversation with a customer. "We don't know Spring," they said. Fine, your choice is the learn Spring's factory or mine and mine doesn't have any documentation, is not as flexible, and is not as well used. I've worked on enough projects and has gotten enough people ramped up on our code to have confidence that people can ramp up quickly.
  37. Re: Misconcieved criticism[ Go to top ]

    We used Spring on a large project (several hundred beans) with mostly junior developers. We only had a couple of people with significant experience with Spring. Even so, it helped us drastically. We had some initial training (mainly presentations during lunch), and that was enough to get everyone to be productive. Our junior developers didn't have to worry about transactions, object factories, or anything of that sort. We had few problems (implementation or usage) with Spring, and were handled by senior developers. Hibernate, on the other hand, caused us a lot problems. Not necessarily the fault of Hibernate, just developers who don't know their database basics. Spring does cover quite a bit of ground, and can take a while to fully understand. The good news is that it isn't necessary to effectively use Spring. If you have one senior developer who does fully understand all of the intricacies of proxies, object creation, etc that should be enough. Spring allows us to keep much of the complexity of enterprise development out of the business logic.
    Spring does have a learning curve. And a large established spring project using aop, annotations, plus an assortment of ad hoc open source technologies, and the spring transactions with annotations and execution blocks mixed in, and 20 odd config files, all including each other, with wiring and config mixed together, and jmx support, bundled with some random soap server etc etc.

    Well, it's a pretty huge elephant. Joining such a project is a very big learning curve, to say otherwise is wrong. Now spriong may only be 30% of that BUT it encourages this type of architecture. i.e. aspects hiding logic, config bloat, inclusion of lots of open source.

    So, I wouldn't say it's FUD, more an observation from someone at the bottom of the learning curve, while you are perched at the top saying it's easy, come on, start climbing.

    Jonathan


    I disagree. In fact, I would say that the learning is much, much smaller than you would think. I've worked with serveral projects and people ranging from very junior to experienced senior and even the junior people have been very productive BECAUSE of the consistency that Spring introduces.

    For example, we use AOP for security, profiling, exception handling, transactions, and caching. The resulting business logic is very clean, clear, and tight. People can proceed to make business logic changes without screwing up say caching.

    People can make security changes without messing up business logic or profiling.

    Hibernate is much easier(and it wasn't hard) to pick up because session management is pulled out of the equation.

    Spring is much easier than dealing with someone's custom factory, database tier, and custom infrastructure.
  38. Re: Misconcieved criticism[ Go to top ]

    We used Spring on a large project (several hundred beans) with mostly junior developers. We only had a couple of people with significant experience with Spring. Even so, it helped us drastically. We had some initial training (mainly presentations during lunch), and that was enough to get everyone to be productive. Our junior developers didn't have to worry about transactions, object factories, or anything of that sort. We had few problems (implementation or usage) with Spring, and were handled by senior developers. Hibernate, on the other hand, caused us a lot problems. Not necessarily the fault of Hibernate, just developers who don't know their database basics.

    Spring does cover quite a bit of ground, and can take a while to fully understand. The good news is that it isn't necessary to effectively use Spring. If you have one senior developer who does fully understand all of the intricacies of proxies, object creation, etc that should be enough. Spring allows us to keep much of the complexity of enterprise development out of the business logic.
    This mirrors my experience. You can actually use Spring to keep people focused on their specific pieces without having to learn everything about it. I had a junior developer do some good work using Spring/Hibernate for searching with the Hibernate criteria API despite never using either before. Again, what I like is that I can hand people Struts, Spring, and Hibernate books and they can get to it. As opposed to some places where you get handed half-completed and obsolete documentation describing their in-house stuff. And guess how portable that particular infomation will be when you leave? You may as well use their in-house database!
  39. Subtle EJB propaganda[ Go to top ]

    I see you’ve started quite a discussion and a good one as well! Rather joining in, I would like to point out some comments on the 10 “misconceptions."
    Spring is not lightweight. It aims to do everything and is becoming fat and bloated.
    Spring is not lightweight. Not if you tend to use everything, that is. It’s modular and scalable and will provide you with lightweight combination that suites your business.
    Spring is overkill for simple applications.
    Also a questionable misconception. It is true Spring introduces a layer of complexity, but it also preserves/enforces good OOD, patterns and model, thus contributing more then it takes.
    Spring does not scale to handle very large applications.
    Also quite false. My bank runs about 50 branches and with more that 1000 employees. Very large financial application is backed up by the Spring 1.2.5 and its scales quite nicely so far. We use Spring container (IoC, beans) and a bit of AOP, that’s all. Additionally, I've developed an EJB-like annotation model and created wrappers for complete Spring, thus hiding it from "daily developers" in order to prevent xml chaos and factories mentioned above. System is reliable and responsive.
    Spring forces you to use Aspect-Oriented Programming (AOP) which is experimental.
    Well, I don't know how to comment this objectively. Neither is a complete truth. You are not forced to use AOP by no means, and it is as experimental as Spring itself.
    Spring replaces Java Enterprise Edition (JEE).
    This is the only misconception I agree completely. But, it's worth mentioning that its not the only thing Spring replaces...
    Spring and EJB are mutually exclusive.
    Wrong.
    Spring cannot take advantage of Java 5 annotations like EJB3 does.
    It's a simple case of metadata style that's considered appropriate by the architects. Both approaches have their good and bad aspects, not worth reasoning about it...
    For a large application, Spring’s XML can become a maintenance nightmare.
    So does any type of configuration of a large system. It's true that EJB3 annotations will prove more maintainable that Spring's XML, thought. But it has its down sides as well, and this is not the place for that story. What is worth reasoning is the amount of pressure introduced on junior developers by xml configuration and java code metadata configuration... All in all, "misconception" is insignificant.
    Spring does everything with reflection, so it is slow.
    This is the weakest “misconception" of all. I frequently quote Mr. Knuth to my colleagues “Premature optimization is the root of all evil.” Spring has some complex algorithms for singleton maintenance and retrieval (source is available). By no means Spring is slow due to reflection, I suggest you test your “misconception" with some benchmarking - you will find Spring slow, as I did, on some awkward places, but not in reflection code.
    Spring MVC is complex and not as simple as the rest of Spring.
    Yes, it is not simple as the rest of the Spring and, yes, it is complex. And yes, you don’t have to use it if you don’t like it. My ten "misconceptions" would address some misbehaviors and new functionalities like invalid bean querying, lack of wiring inner classes as inner beans, absence of reference wiring, no reconfiguration infrastructure etc.
  40. Spring is a thing of beauty[ Go to top ]

    Re: 1. Spring is not lightweight For what it does, it is surely lightweight. We are using Spring, Kodo and ACEGI. So it handles security and transactions. Using an appserver would be more costly and heavyweight. 9. Spring uses reflection and so it is slow If you used an app server for security and transactions I am pretty it would be much slower. As a developer who worked on the development of an app server, I can vouch for this.
  41. Randy you don't get it[ Go to top ]

    The whole of the spring distribution is large. That does not stop or affect the fact that spring is light weight. If you only use the IOC thats all that will be loaded into memory thats how java works.

    What I find amusing is that this statement also applies to JavaEE app servers, which the Spring folks have historically derided with "heavyweight", "don't make me eat the elephant", etc. It seems the criterion should apply equally to both.
    You simply don't get it... Now that is fine... you will get it eventually if you are willing to put in some effort... Read some spring books try it out etc... However please to NOT make any PUBLIC comments until you have done so... Because your post is pointless... and you are cloging up the thread.. And here is and explanation of WHY your post is pointless: The REASON JEE is labeld "heavyweight" has NOTHING, NOTHING, NOTHING to do with the SIZE of the distribution... Who cares how large a distrbution is on a server.... The POINT of the heavyweight is about the IMPACT (lets say the footprint) of the framework in your code... Eg how many classes you HAVE to extend or interfaces you must implement, or restrictions on what you can do. Take EJB for example...Remote interface, Home interface etc The reason spring is called "Lightweight" is because it is lightweight with respect to the footprint in your application code... You don't have have to implement lots of interfaces etc.. in many areas... It is transparent...
  42. Re: Randy you don't get it[ Go to top ]

    I do get it. The point the previous poster made was that even the Spring distribution is large, Spring was still "lightweight" because only the parts being used are loaded into memory. Well, that's true of JavaEE app servers also. Has been for a long time. If you want to talk about how "lightweight" means that the framework doesn't impact your code, is transparent, etc. (why are there so many definitions of "lightweight"?), that's true of JavaEE5 app servers also. If you don't think so, you may need to go back and take another serious look at JavaEE5, EJB3, and JPA. My point is that the terms "lightweight" vs. "heavyweight" been tossed around, mainly by Spring adherents but by other JavaEE-bashers as well, as a FUD-spreading smokescreen to further their cause. Threads like this one indicate that the smoke is starting to clear.
  43. Re: Randy you don't get it[ Go to top ]

    I do get it.

    The point the previous poster made was that even the Spring distribution is large, Spring was still "lightweight" because only the parts being used are loaded into memory.

    Well, that's true of JavaEE app servers also. Has been for a long time.

    If you want to talk about how "lightweight" means that the framework doesn't impact your code, is transparent, etc. (why are there so many definitions of "lightweight"?), that's true of JavaEE5 app servers also. If you don't think so, you may need to go back and take another serious look at JavaEE5, EJB3, and JPA.

    My point is that the terms "lightweight" vs. "heavyweight" been tossed around, mainly by Spring adherents but by other JavaEE-bashers as well, as a FUD-spreading smokescreen to further their cause. Threads like this one indicate that the smoke is starting to clear.
    Nope. It just means that the perceived number 1 item is always attacked by "self-proclaimed" rebels. Twas ever thus. It's strange that the people who attack Spring the most never actually used it. It's always "I think this..." or "My impression is that..."
  44. It's strange that the people who attack Spring the most never actually used it. It's always
    "I think this..." or "My impression is that..."
    I am not attacking Spring, just the misleading, squishy, "lightweight vs. heavyweight" argument. Nor have I said "I think this.." or "My impression is that..." anywhere. :) Heh...however, just above, someone posted "Using an appserver would have been more costly and heavyweight." And "I am pretty it would be much slower." Blech.
  45. 1.Java is hard. The java API's need hiding. 2.Compilation is rubbish. Why solve all typing and symbol mapping at compile time when there are so many frameworks that allow runtime validation. 3.Property files are bad. You should always use XML no matter how trivial. And better yet, you should mix config with symbol mapping in the same file. 4.RMI is rubbish, even in JDK1.5. You need to have a framework to use it. 5.JDBC is rubbish because all the exceptions are verbose. Hide it all from developers. 6. Transactions are uber complex. Never allow developers to do transaction managers. 7. Never ever have a main function. If your java code has a main then it is a 'process' and is running natively. This is a bad thing. 8. OO cannot handle common problems. Logging and security and security and logging, and lets not forget security and logging, and logging all need an orthogonal approach. Aspects are the way. And dynamic projects are fantastic - unless you are calling a private method which needs security and logging, but if you are doing that you are rubbish. Nathan Ludite.
  46. projects = proxies.
  47. I won't ask the obvious question about the intellect of some of the posters on this thread... They make that clear from their "argument less throw away statement" based posts... I originally submitted this post to SS but Joseph seemed to beat me to it..hmm. The reason I posted it was just to see the hilarious post of the Java dabblers... The ones who have never used spring. See if you can spot them above ( lol) Of the many post by the dabblers the most funny ones are: 1) Comparing Spring directly to EJB3. That is like comparing the java language to the apache web server.:) 2) Saying spring is not lightweight... The POINT of the lightweight is NOT the size of the jar files (sorry lol, that is a good one). It is about it's footprint within your application. Ha ha I will make it simple for you... it is about how many times you have org.springframework... referenced in your import statements. 3) Saying spring does to much, so it is too big... That is the POINT you id**ts !!!. It is a framework/toolkit... Just use the bits you want. Just like you do in Java. How time do you use AWT in a web based app ???? But it is still there if you want it. What's more spring is specifically designed for this... it couldn't be easier... They even split the distribution jar's up for you... So my last point... If you haven't got anything constructive to say don't say anything at all... And remember have a POINT have and ARGUMENT, have some EVIDENCE and finally have some EXPERIENCE before you feel you need to spread your FUD and clogg the thread with your stupid posts... Pete
  48. 3) ... It is a framework/toolkit... Just use the bits you want. Just like you do in Java. How many times do you use AWT in a web based app ???? But it is still there if you want it. What's more spring is specifically designed for this... it couldn't be easier... They even split the distribution jar's up for you...



    Pete
    I think you really nailed that point.It seems choice and bloat looks the same to some people. If you don't want to use Spring MVC for example go ahead use Webwork, Stripe, Wicket, Struts,JSF e.t.c spring doesn't stop you from doing that. I consider spring lightweight because i don't necessarily need a full blown appserver for each and every app(Easily scale up and down according to your requirements).Hey i can even instantiate the container from the main method.
  49. 3) ... It is a framework/toolkit... Just use the bits you want. Just like you do in Java. How many times do you use AWT in a web based app ???? But it is still there if you want it. What's more spring is specifically designed for this... it couldn't be easier... They even split the distribution jar's up for you...



    Pete


    I think you really nailed that point.It seems choice and bloat looks the same to some people. If you don't want to use Spring MVC for example go ahead use Webwork, Stripe, Wicket, Struts,JSF e.t.c spring doesn't stop you from doing that.

    I consider spring lightweight because i don't necessarily need a full blown appserver for each and every app(Easily scale up and down according to your requirements).Hey i can even instantiate the container from the main method.
    Agreed. Our main code had no Spring imports. Where I am dependent on Spring is 1)In Struts, where I use a Spring factory to instantiate a particular business object 2)AOP, which you don't see in the business logic. And even my inteceptors just have javabeans injected in that does the work. 3)Spring/Hibernate integratoin hidden up the class chain by a base class. The derived DAOs have no knowledge of Spring. Also, I've used Spring for apps as small as two pages. It scales down very nicely, IMO.
  50. Hi David I see your point you clearly understand spring and i agree it scales in both directions. However David, would you not agree that what you stated there is more of an "indirect" dependency on spring. I see your argument that you have a hidden dependency on spring but that is becauase you want to. Simply because it makes life easier for you :) So just to extend David's point. He could if he wanted to pull out spring and technically (if the app is built in layers/interfaces) not have to change any front line code. (Eg model, controller views etc). And the find a replacement for all the transparent services (aka magic) springs provides. It would be hell to replace...but in theory it could be done... But the question is not can it be done... rather why would you want to :)
  51. Why remove spring? First of all, for Pete and his ilk, been using spring in prod for over 2 years. I think the question should be reversed to 'Why use spring?' Not why use Spring rather than EJB123 - we all know the answer to that, it far far better. But, why use spring at all is a better question. Lots of snr developers are coming out of big spring projects swearing never to use it again. Not because it's bad in every respect, but because they see no point to it, and they hate the coding by XML that it brings into enterprise systems. You can use plugable soap servers, pluggable logging, connection pools, and rmi servers. These seem to be the common open source components on all projects. Even Spring prides itself on this - ie pluggable. So, if we agree none of those are spring attributes we are left with the question of 'what is spring?'. To say it's a toolset is a little misleading, the tools in it's set are independant of spring in the most part. In fact, if you really look at it, the main thing about spring is the dynamic proxies, the xml config and singleton/non singleton beans and the bean creation factory (auto creation of dependants etc, IOC). At this point you can say:- 'I love autowiring and spring is the best impl, and dynamic proxies are OK once you get them'. OR 'I really can't be bothered with the level of buyin to this stuff, I'll choose something smaller, or write java without this stuff. I can do my own object creation and I don't need an ascii file to do it for me.' And I think that is actually the differential. Also, it's the current sexy thing, which is important until you have done it. Of all the frameworks I've yet used, spring is still the best. But you don't need to use a framework, in which case the choice is less obvious. Ask a sample of snr devs after they have left a spring project and the overall impression is very, extremely mixed, and tends towards 'never again' - OK, small sample set :), thats 5 devs who left, and 3 hated it, and the other 2 were neutral. Just as a game, take your current project architecture and design it without spring, is it simpler, more complex or about the same? Jonathan (embracing all shiney new things)
  52. Interesting post Jonathan... Yes of course i don't NEED spring in the way i NEED java...(i am a java developer) And yes i COULD write my owning GLUE code... Singleton, factories, custom configuration readers... But why would WANT to spend my time writing that code when I SHOULD be writing the business logic etc code for my actual application. This is the way i see it: Its all about choices to make my life easy: PROBLEM: i am building user application that responds to request from a browser. OPTIONS: i ONLY know java inside out so it has to Java. So do I: 1) build a webserver from scratch using java sockets 2) build a servlet sitting on top of the JEE stack For me i choose 2 means more time for me to build my app. NEXT: The application is gonna take user input via forms and i would like to abstract out views from the the controllers so really talking about MVC... OPTIONS AGAIN: 1) Do i stick with servlets and roll my own MVC framework on top of that. 2) Do i choose a tried and tested existing Open source MVC framework. For me i choose 2 means more time for me to build my app. NEXT: I would like to define some clear layers in the application (persistance, business, view) I would like the option to change implementations of these without dependent code being affected... OPTIONS AGAIN: 1) Do i use my java skills and create my own DI framework abstracting out creation of my layers etc. 2) Do a choose a tried and tested existing Open source DI framework that handles this scaffolding code in a robust CONSISTENT way... For me i choose 2 means more time for me to build my app. So for me, after the choices i made i finally end up with with my BASELINE application. STARTING POINT if you like. Before i have written a single line code of my ACTUAL application: That is from top down: JSP/JSLT Spring MVC Spring core (DI,AOP,services and magic!!!) Hibernate So by choosing this stack from the START... i get to spend 98% of my time actually writing the code for my application and 2% wiring it all up via the choosen frameworks. So i chose spring because: IT MEANS MORE TIME FOR ME TO BUILD MY APP !!! Interestingly i have now CONVERTED 3 large 2 small web application now using a mixture of EJB, struts, home grown MVC, home grown DAO's etc to using the Stack to described above. And on everyone Spring has made the applications exponentially simpler... Simpler to maintain Simpler to test Simpler to extend Plus is keeps junior developers on a leash :) Peace :)
  53. Why use Spring[ Go to top ]

    Jonathan - I'm curious what the reasons are why your sr developers said "never again" about Spring. I think I agree with most posters in that sure, sometimes the XML is unwieldy (but as been pointed out, anytime you use a lot of something, it tends to get unwieldy - take the original struts-config.xml file as an example), but otherwise, I can't think of how Spring would get in my way such that I'd say "never again" about it. Anyways, in answer to your question - I can give you a good comparison of a project I worked on starting in fall 03 and another project happening down the hall that started at the same time. We used the Spring container (and Webwork 1.x since I had used it before). It worked out great for us - we pretty much used the basics, like transaction proxies and Hibernate/JdbcTemplate, and we later used the Quartz support as well. It was a fairly large project where we ended up with 7 files (4 based on tiers (core/dao/service/web), and 3 based on Quartz and 2 sets of 3rd-party software) with a few hundred beans, but with some good organization, the XML really wasn't ever an issue. The other project didn't use Spring, and when I looked at their codebase a couple years later, I found 1) a fully homegrown configuration framework, 2) many, many custom factory classes that depended on the config framework, 3) many, many static method calls and tight bindings, and 4) a ton of object creation that didn't really need to be happening because many of the objects were (or should have been) threadsafe. A lot of that can be chalked up to a fair number of new Java developers on the project, but here's the thing - that was also the case on my project, and I found Spring to be perfect for helping new developers understand concepts like loose coupling, how to use interface classes, and basically a lot of good design principles. So from that very small comparison, I think 2 benefits of Spring are that you're probably going to end up writing your own factory classes anyway, as well as either writing or adopting a config framework, so why not use Spring's and avoid all that effort? - and that Spring arguably promotes good design practices. Obviously, good design is in no way/shape/form dependent on Spring or any framework, but I do think Spring helps.
  54. Re: Why use Spring[ Go to top ]

    Most of my dev mates are using ruby now - shinier than spring! I'm not working in that space anymore so can't comment, although I know some people who put the effort into JSF and love it. Last time I worked in web it was Tomcat and Struts (and I still have some of that stuff running). Jonathan
  55. Re: Why use Spring[ Go to top ]

    I agree spring creates a common coding standard - and I think this is a very big plus point. But, the guys that left had all done plane java projects before, done ejb, done global strategic C++ on unix/linux etc. And from their point of view the problems that spring solved were not problems at all. You don't need anything spring has to code these solutions. I also have seen homegrown frameworks - they read the book and create a monster. Again spring wins. But, should you tie yourself to Spring if your devs don't need it? Or should you tie yourself to it in the expectation that all/some of your developers are bad. i.e. is the argument for spring simply one of 'staff risk'. In which case the argument is not pro spring, but pro 'simple standards enforced thru code'. Spring being the best of the current batch. It's certainly a strong argument, but not one rooted in technology, more one rooted in people and their ability to work to standards. Cheers, Jonathan
  56. Re: Why use Spring[ Go to top ]

    But, the guys that left had all done plane java projects before, done ejb, done global strategic C++ on unix/linux etc. And from their point of view the problems that spring solved were not problems at all. You don't need anything spring has to code these solutions.
    That's also my impression. Spring gives you flexibility and configurability where you don't need it. At the cost of (XML) configuration overhead and runtime errors.
  57. Hi David

    I see your point you clearly understand spring and i agree it scales in both directions.

    However David, would you not agree that what you stated there is more of an "indirect" dependency on spring. I see your argument that you have a hidden dependency on spring but that is becauase you want to. Simply because it makes life easier for you :)

    So just to extend David's point.

    He could if he wanted to pull out spring and technically (if the app is built in layers/interfaces) not have to change any front line code. (Eg model, controller views etc). And the find a replacement for all the transparent services (aka magic) springs provides. It would be hell to replace...but in theory it could be done...

    But the question is not can it be done... rather why would you want to :)
    I would agree with indirect, certainly. For example, I have Object A, that has injected into it Objects B and C. Remove the Spring bean factory and someone has to construct this object. I had a similar conversation with a customer a couple of weeks ago. They stated that there people didn't know Spring and they didn't want to use it. So I provide a static class with a "factory" that would create an object for them. Inside this class, I used Spring. I informed them that if didn't want to use that "factory" AND they didn't want to modify anything, just create A, B, and C using new() and call the appropriate getters and setters. "However", I stated, "you would need to at least look at the XML file to know what need to go where." They found that acceptable.
  58. +1