Discussions

News: Spring in 2006: A year in review

  1. Spring in 2006: A year in review (98 messages)

    At the Spring Experience last night Spring founder Rod Johnson declared that Spring became ubiquitous in 2006, and that it had become a defacto standard. Rod did a review of what happened in 2006 to drive such strong growth for Spring: Februrary. - Arjen Poustma joins Interface21, focused on Spring Web Services. May - Spring gets a gold award for innovation at the JAX conference in Germany. - Pitchfork released in cooperation with BEA who is using Spring inside WebLogic. - Oracle also announces Spring integration, and that Oracle Developer Depot runs Spring - Acegi Security goes 1.0 June - French online tax portal based on Spring goes into production - handles taxation for 34 million users - Spring One held in Antwerp, belgium July - Voca payment engine goes live in the UK, coinciding with Rod's birthday. Voca has handled 80M transactions since. Voca processses direct debits, credits, and money orders between banks. August - Spring LDAP joins the Spring portfolio - Interface21 trains its 1000th developer on Spring, they have a huge list of upcoming trainings September - Spring gets it's 1 millionth download October - Spring 2 final releases. 12,000 downloads in the fist 24 hours - Spring Web Flow goes 1.0 final. - Former Solarmetric co-founder Neelan Choksi joins I21 from BEA, where he managed the open sourcing of Kodo as the OpenJPA project. Adrian Colyer and Ramniavs Laddadd also joined I21 last year. 2007 will be an even more exciting year, according to Rod. Upcoming are releases of Spring OSGi, Spring Web Services, and further improvements to Spring Web Flow.

    Threaded Messages (98)

  2. This site should change its name to "TheSpringSide". Seriously, the day Spring gets ubiquitous is going to be the day where the majority of Java developers will flee to other languages and platforms. Working in unmanagable mess of XML configurations makes us "unhappy", as would some zealot say.
  3. "Nearly" ubiquitous?[ Go to top ]

    Perhaps Rod overstated his case slightly, but not by much! Almost all the other open-source libraries I've looked at this year include some kind of Spring integration, or at least some documentation on how they would work together. Whether you like it or not is another, completely valid question (I don't mind, myself). But yes, Spring has become "nearly" ubiquitous over the past year... Fortunately for you, that just means it's available nearly everywhere, not that you are going to be forced to use it or any other technology.
  4. Re: "Nearly" ubiquitous?[ Go to top ]

    But yes, Spring has become "nearly" ubiquitous over the past year... Fortunately for you, that just means it's available nearly everywhere, not that you are going to be forced to use it or any other technology.
    Oh really? I would like to see "how much ubiquitous" that is but unfortunately I only seem to find it in "TheSpringSide" and in Jroller.
  5. Re: "Nearly" ubiquitous?[ Go to top ]

    Oh really? I would like to see "how much ubiquitous" that is but unfortunately I only seem to find it in "TheSpringSide" and in Jroller
    Try dice.com. Today there are 1552 Spring jobs.
  6. Welcome Thiago! No thread about Spring would be complete without you.
    Seriously, the day Spring gets ubiquitous is going to be the day where the majority of Java developers will flee to other languages and platforms.
    In my keynote I underpinned my statements with facts, references and verifiable success stories. As usual, you do not. Merriam-Webster defininitions for ubiquitous include "widespread" and "constantly encountered." These accurately characterize Spring adoption in enterprise Java. Here at the Spring Experience conference in Florida, we have over 400 attendees, with real experience using Spring and who are happy about the results it has brought them. Our sponsors include BEA and Oracle. Several of our speakers are JCP spec leads. We have attendees from many of the Fortune 500, and some of the world's leading systems integrators. We have leaders from other prominent open source projects including Mule, Geronimo, OpenJPA and TopLink Essentials...
  7. Merriam-Webster defininitions for ubiquitous include "widespread" and "constantly encountered." These accurately characterize Spring adoption in enterprise Java.
    Does that makes it "ubiquitous" as in worldwide? I know a few Struts projects that has just started, but I wouldn't dare to say Struts is the future. Anyway, time will tell. Java developers lately seems to be prone to idiocy, this one will be the nail in the coffin, but you know what? Tell us if I am wrong in 5 years.
  8. you bick witty[ Go to top ]

    Seriously, the day Spring gets ubiquitous is going to be the day where the majority of Java developers will flee to other languages and platforms.
    That day has already come and gone. A majority of our customers use Spring, and are widely using Spring in new projects. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  9. This site should change its name to "TheSpringSide". Seriously, the day Spring gets ubiquitous is going to be the day where the majority of Java developers will flee to other languages and platforms.

    Working in unmanagable mess of XML configurations makes us "unhappy", as would some zealot say.
    Many of us are quite happy with both Spring and its XML configuration. We've just released another Spring based product and the customers are again pleased. We are now preparing for 07 and another Spring(now 2.0). Keep it coming. If the "majority" of Java developers flee, then my services become all the more valuble. So flee!!!
  10. Keep it coming. If the "majority" of Java developers flee, then my services become all the more valuble.

    So flee!!!
    Remember, they will flee to create products with more capable technologies. Be careful for what you wish for, you might eventually get it. :)
  11. Keep it coming. If the "majority" of Java developers flee, then my services become all the more valuble.

    So flee!!!


    Remember, they will flee to create products with more capable technologies. Be careful for what you wish for, you might eventually get it. :)
    I'm not losing any sleep. If the majority of Java developers flee because of Spring as stated, I only see a brighter future for me. I've moved from C to C++ to Java and I have no doubt that I will move again. But it won't be because of any single factor.
  12. Re: Spring in 2006: A year in review[ Go to top ]

    Keep it coming. If the "majority" of Java developers flee, then my services become all the more valuble.

    So flee!!!


    Remember, they will flee to create products with more capable technologies. Be careful for what you wish for, you might eventually get it. :)


    I'm not losing any sleep. If the majority of Java developers flee because of Spring as stated, I only see a brighter future for me.

    I've moved from C to C++ to Java and I have no doubt that I will move again. But it won't be because of any single factor.
    Hi David, Why move, why not just add? I started with Modula-2, then added C, then C++, then Smalltalk, a little Eiffel, then emacs-lisp, then Java, then Ruby, I'm now looking to add Common Lisp, Caml and Python. They are all useful. The trick is picking the right tool for the job. Paul.
  13. Re: Spring in 2006: A year in review[ Go to top ]

    Keep it coming. If the "majority" of Java developers flee, then my services become all the more valuble.

    So flee!!!


    Remember, they will flee to create products with more capable technologies. Be careful for what you wish for, you might eventually get it. :)


    I'm not losing any sleep. If the majority of Java developers flee because of Spring as stated, I only see a brighter future for me.

    I've moved from C to C++ to Java and I have no doubt that I will move again. But it won't be because of any single factor.


    Hi David,

    Why move, why not just add?

    I started with Modula-2, then added C, then C++, then Smalltalk, a little Eiffel, then emacs-lisp, then Java, then Ruby, I'm now looking to add Common Lisp, Caml and Python.

    They are all useful. The trick is picking the right tool for the job.

    Paul.
    Because I'm motivated also by what I enjoy. I no longer enjoy C or C++. My moving from C/C++ is no indictment of C/C++, but more a change in my tastes. I follow to varying degrees many of the things you mentioned, but they are not currently compelling to me. I don't feel like I've exhausted what I can learn or experience in the Java world. In addition, I seek out work that reflects my interest, so naturally, Java is the best fit, for me. When something better finally comes along, I'll move on.
  14. Re: Spring in 2006: A year in review[ Go to top ]

    Why move, why not just add?

    I started with Modula-2, then added C, then C++, then Smalltalk, a little Eiffel, then emacs-lisp, then Java, then Ruby, I'm now looking to add Common Lisp, Caml and Python.

    They are all useful. The trick is picking the right tool for the job.

    Paul.


    Because I'm motivated also by what I enjoy. I no longer enjoy C or C++. My moving from C/C++ is no indictment of C/C++, but more a change in my tastes.

    I follow to varying degrees many of the things you mentioned, but they are not currently compelling to me. I don't feel like I've exhausted what I can learn or experience in the Java world.

    In addition, I seek out work that reflects my interest, so naturally, Java is the best fit, for me.

    When something better finally comes along, I'll move on.
    Hi David, An understandable point of view, and fun has played it's part in me taking a look at certain languages too. Something to bear in mind though, is that all languages are a compromise to some degree. There is no perfect language, and I tend to find that ideas and concepts picked up in one language inform my use of another. For example Eiffel was very informative when it came to the idea of design by contract - which I apply today with Java. Also, Smalltalk is extremely informative when it comes to OO design, and it helped me tell were hybrid languages like C++/Java are true OO and areas where they fall short. Compared with the number of dud API's I've learned over the years, I can't think of a single example where time invested in learning a language has been a waste. It as always led to me becoming a better programmer overall. The other point worth considering is that some languages are like certain foods, they are an acquired taste. You may hate them at first, but once you gain an appreciation of their charms they grow on you. For example I never thought that I would enjoy programming in Lisp, but I do. I guess you are happy with your choices, and I accept that. Just some points to ponder. Paul.
  15. Re: Spring in 2006: A year in review[ Go to top ]

    Why move, why not just add?

    I started with Modula-2, then added C, then C++, then Smalltalk, a little Eiffel, then emacs-lisp, then Java, then Ruby, I'm now looking to add Common Lisp, Caml and Python.

    They are all useful. The trick is picking the right tool for the job.

    Paul.


    Because I'm motivated also by what I enjoy. I no longer enjoy C or C++. My moving from C/C++ is no indictment of C/C++, but more a change in my tastes.

    I follow to varying degrees many of the things you mentioned, but they are not currently compelling to me. I don't feel like I've exhausted what I can learn or experience in the Java world.

    In addition, I seek out work that reflects my interest, so naturally, Java is the best fit, for me.

    When something better finally comes along, I'll move on.


    Hi David,

    An understandable point of view, and fun has played it's part in me taking a look at certain languages too.

    Something to bear in mind though, is that all languages are a compromise to some degree. There is no perfect language, and I tend to find that ideas and concepts picked up in one language inform my use of another. For example Eiffel was very informative when it came to the idea of design by contract - which I apply today with Java. Also, Smalltalk is extremely informative when it comes to OO design, and it helped me tell were hybrid languages like C++/Java are true OO and areas where they fall short.

    Compared with the number of dud API's I've learned over the years, I can't think of a single example where time invested in learning a language has been a waste. It as always led to me becoming a better programmer overall.

    The other point worth considering is that some languages are like certain foods, they are an acquired taste. You may hate them at first, but once you gain an appreciation of their charms they grow on you. For example I never thought that I would enjoy programming in Lisp, but I do.

    I guess you are happy with your choices, and I accept that. Just some points to ponder.

    Paul.
    I've read many of your post Paul. No offense, but you seem to think that no one is capable of putting in as much thought as you, and STILL arrive at a different decision. As I said, I've looked into and have experience with several languages beyond what I post. I've tried Lisp also. I don't like. I understand it, and still don't like it. It is possible to understand something and still not like it or agree with it. You like Lisp and that's fine, but that makes us different.
  16. Re: Spring in 2006: A year in review[ Go to top ]

    Why move, why not just add?

    I started with Modula-2, then added C, then C++, then Smalltalk, a little Eiffel, then emacs-lisp, then Java, then Ruby, I'm now looking to add Common Lisp, Caml and Python.

    They are all useful. The trick is picking the right tool for the job.

    Paul.


    Because I'm motivated also by what I enjoy. I no longer enjoy C or C++. My moving from C/C++ is no indictment of C/C++, but more a change in my tastes.

    I follow to varying degrees many of the things you mentioned, but they are not currently compelling to me. I don't feel like I've exhausted what I can learn or experience in the Java world.

    In addition, I seek out work that reflects my interest, so naturally, Java is the best fit, for me.

    When something better finally comes along, I'll move on.


    Hi David,

    An understandable point of view, and fun has played it's part in me taking a look at certain languages too.

    Something to bear in mind though, is that all languages are a compromise to some degree. There is no perfect language, and I tend to find that ideas and concepts picked up in one language inform my use of another. For example Eiffel was very informative when it came to the idea of design by contract - which I apply today with Java. Also, Smalltalk is extremely informative when it comes to OO design, and it helped me tell were hybrid languages like C++/Java are true OO and areas where they fall short.

    Compared with the number of dud API's I've learned over the years, I can't think of a single example where time invested in learning a language has been a waste. It as always led to me becoming a better programmer overall.

    The other point worth considering is that some languages are like certain foods, they are an acquired taste. You may hate them at first, but once you gain an appreciation of their charms they grow on you. For example I never thought that I would enjoy programming in Lisp, but I do.

    I guess you are happy with your choices, and I accept that. Just some points to ponder.

    Paul.


    I've read many of your post Paul. No offense, but you seem to think that no one is capable of putting in as much thought as you, and STILL arrive at a different decision. As I said, I've looked into and have experience with several languages beyond what I post. I've tried Lisp also.

    I don't like. I understand it, and still don't like it. It is possible to understand something and still not like it or agree with it.

    You like Lisp and that's fine, but that makes us different.
    Hi David, No offence taken. Like I said, I guess you're happy with your choices. It would be interesting to know what languages you have tried though. Paul.
  17. Re: Spring in 2006: A year in review[ Go to top ]

    Java, C/C++, TCK/TK, VB, FORTRAN, cmd line scripting(csh,etc...)- Actually paid PASCAL, LISP, some funky AI language I can't pull now, C#, PERL, PHP - hands on experimentation to varying degrees beanshell, groovy, ruby - read about, haven't tried or couple lines of code
  18. Re: Spring in 2006: A year in review[ Go to top ]

    Java, C/C++, TCK/TK, VB, FORTRAN, cmd line scripting(csh,etc...)- Actually paid

    PASCAL, LISP, some funky AI language I can't pull now, C#, PERL, PHP - hands on experimentation to varying degrees

    beanshell, groovy, ruby - read about, haven't tried or couple lines of code
    Hi David, I guess we are all products of our experiences. Out the list of languages I've tried, the one that has had the biggest impact on me is Smalltalk. This is why I find what passes as OO programming amongst the C++/Java/C# community distressing. This is the perspective I bring to the debate. BTW I would not want to program in Lisp on a daily basis either, but I have found that Lisp improves my Ruby and Ruby is the next best thing I've tried to my beloved Smalltalk. I just find it hard to understand your harsh views against a language like Ruby when you openly admit that you have only read about it.
    No offense, but you seem to think that no one is capable of putting in as much thought as you, and STILL arrive at a different decision.
    No Offense, but I've done alot more the just read a bit about dynamic, pure OO languages like Smalltalk and Ruby. Paul.
  19. Re: Spring in 2006: A year in review[ Go to top ]

    My "harsh" views are pretty straightforward. I don't believe that, based on history, that dynamic languages are the next big thing. This is admittedly, based on the history of successful languages. I never said that a particular feature, in say, Ruby, wasn't useful. For example, closures look useful. But it seems that it will be incorporated into Java. I think that Java will be replaced by another statically typed language. Also, based or the features of Ruby, I don't find it compelling based on what I can already do with Java. Java, before I tried, had several compelling features that made it worth, to me, trying. The framework doesn't offer me anything that I can't get with my current toolset and seems, at least when I last looked, a bit limited. Based on the various posts I've read, Rails, the killer app of Ruby, simply isn't that compelling. Could that change? Perhaps. When it does I simply don't think something like Ruby will be, JavaXT, C#2, or some other thing. Lisp, well, I just didn't care for it. It never interested me enough to go pursue. Yet, Spring did. Go figure. No offense taken. I read TSS to find out about stuff. I found out about things like Spring, Idea, OSCache, Hibernate, etc at this site, so bring on the debate, I say. I do feel that I don't need to have direct experience with Ruby to challenge a statement claims that Spring is a direct line to Ruby or that Dynamic languages are necessarily the next big step. What you won't find me doing is hitting say a forum about Ruby talking about how bad it is when I don't have any direct experience with it.
  20. Re: Spring in 2006: A year in review[ Go to top ]

    Edit, when I said "based or the features of Ruby" I meant "based on the features of Rails"
  21. Re: Spring in 2006: A year in review[ Go to top ]

    I think that Java will be replaced by another statically typed language.
    ....or that Dynamic languages are necessarily the next big step.
    +1 The dynamic vs static language debate has been going on since LISP vs Algol and FORTRAN more than 4 decades ago. Dynamic languages have been the next big step for a very long time now...
  22. I just find it hard to understand your harsh views against a language like Ruby when you openly admit that you have only read about it.
    I have only read about it too and I think it stinks. It's ugly, slow, insecure and over-hyped. I still didn't find a single human being that can translate the "awesomeness" of Ruby in words humans can read. It seems to involve some sort of faith, some belief in the future in ways that I, unfortunately, can't afford. Also the person must throw away any notion of "big picture", "macro vision", you name it, in order to accept it as the lord and savior. The book I found in the Ruby website for learning it is a kind of "porn for geeks" thing. It doesn't touch real world scenarios, just expose stupid trickery. You can notice a pattern though, the Java developers that say the best things about it passed through the hell of Spring. I can't really blame them.
  23. ...the hell of Spring
    Yes its been a really terrible year for me using Spring. Development has got easier and more managable and I am able to offer more features/more changes in shorter periods of time. Basically Spring has helped in making the project I am working on better from all points of view (business, management and development) It has been hell...
  24. Re: Spring in 2006: A year in review[ Go to top ]

    ...the hell of Spring


    Yes its been a really terrible year for me using Spring. Development has got easier and more managable and I am able to offer more features/more changes in shorter periods of time. Basically Spring has helped in making the project I am working on better from all points of view (business, management and development)

    It has been hell...
    We've got a little time to kill so, using Spring(AOP as well as configuring the other two tools), Quartz, and OSCache, we are creating a couple of jobs that will cache certain data each morning before the users hit the system. No changes to any core logic required, fully configurable, can be turned off easily if so desired. I've got a junior guy working on it. Starting today, he'll probably finish by tomorrow. So much for hard.
  25. Re: Spring in 2006: A year in review[ Go to top ]

    Keep it coming. If the "majority" of Java developers flee, then my services become all the more valuble.

    So flee!!!


    Remember, they will flee to create products with more capable technologies. Be careful for what you wish for, you might eventually get it. :)
    I wondered who had snagged Rolf's crystal ball. The thing is just as cloudy in misinformed as ever. :( :)
  26. Re: Spring in 2006: A year in review[ Go to top ]

    Mark
    I wondered who had snagged Rolf's crystal ball. The thing is just as cloudy in misinformed as ever. :( :)
    That's funny. Although perhaps a bit of an in-joke--a real blast from the past :-) R
  27. Re: Spring in 2006: A year in review[ Go to top ]

    lol, Rolf was an interesting character indeed. There was another guy, George J, but if I'm not mistaken he may have changed his perspective on Spring. If he did, that's quite a brave move.
  28. lol, Rolf was an interesting character indeed. There was another guy, George J, but if I'm not mistaken he may have changed his perspective on Spring. If he did, that's quite a brave move.
    I think he was more of a bot :p
  29. Re: Spring in 2006: A year in review[ Go to top ]

    There was another guy, George J, but if I'm not mistaken he may have changed his perspective on Spring. If he did, that's quite a brave move.
    Mario, I have not had a 'perspective' on Spring, but JSF. And I have not changed my 'perspective' on JSF. I was only once trying to defend a poor guy who was abused by Spring followers such as Alexandre.
  30. Re: Spring in 2006: A year in review[ Go to top ]

    Mark
    I wondered who had snagged Rolf's crystal ball. The thing is just as cloudy in misinformed as ever. :( :)

    That's funny. Although perhaps a bit of an in-joke--a real blast from the past :-)

    R
    lol, Rolf was an interesting character indeed. There was another guy, George J, but if I'm not mistaken he may have changed his perspective on Spring. If he did, that's quite a brave move.
  31. Re: Spring in 2006: A year in review[ Go to top ]

    Struts has been fading out. But Struts was a very successful project. I am sure there will be something in the future that will replace the Spring. No technology will be there forever. Something out there will replace Java too eventually. According to your way of reasoning, Java would be a failure too. Is that so? Spring is not perfect. But I definately prefer it to anything else(if any out there) for my middler tier development. What I am worreid about is that it will eventually become too complex and too big as it already is. I have seen developers shy away from it just because of its sheer complexity. It really becomes too much work for small projects. But hey, it is hard to please all....
  32. Seriously, the day Spring gets ubiquitous is going to be the day where the majority of Java developers will flee to other languages and platforms.
    At least, Spring is ubiquitously hyped :-)
    Working in unmanagable mess of XML configurations makes us "unhappy", as would some zealot say.
    Even the master sees the XML problem and offers a configuration option: http://blog.interface21.com/main/2006/11/28/a-java-configuration-option-for-spring/
  33. At least, Spring is ubiquitously hyped :-)
    Hehe, that's right!
  34. What XML mess ?[ Go to top ]

    Working in unmanagable mess of XML configurations makes us "unhappy", as would some zealot say.
    We have been using Spring Framework for the past two years in the development a consumer portal (4M - 6 M users base) and it saves us so much effort when we try to rewrite the site and bring new enhancements into the new 100% Spring enabled code base easily. We actually retired a lot of our own internal frameworks and configure almost all of our applications inside of Spring XML. Just to name a few here about what kind of activities we can do quickly now, 1. We can add an MBean operation in 5 sec. 2. We can configure a cron job type of timer in 5 sec. 3. We can include/exclude an AOP Performance test reporting capability in 5 sec. (JETM, http://jetm.void.fm/ => IMHO, this is the best design/implementation for the Spring AOP, using Maven goal, w/o one line of codes or XML change, we can easily apply the AOP performance test output by adding or removing some jars.) etc,.... Of course Spring Framework alone can not be a silver bullet. We use Maven (1.0.2) and carefully divide our contexts into smaller projects so we can clearly identify the dependency among them. We also define our domain Model using AndroMDA (UML) so we can apply template and behavior to our domain model easily. (Most of our backend are MQ & Web Services now, so I can't really comment on the Hibernate & Transaction related parts.) In our Web Tier project, we only have about 50 Java files where they have to be tied to the App Server. Everything else is in the individual Eclipse projects (jars). When developers get used to them, they become very productive in less than one week. (Nodaway, we have so many off-shore resources just come and go.) We are not even using any Spring Plug-in in Eclipse. Developers know how to search for the Beans in the XML even though they might be in different projects. 95% of our beans are singletons so we know there should be only one Bean definition in the entire XML space. We also have defined clear patterns for the names of the Java codes (from different middle-tier layers) and the naming patterns of the XML contexts. All the above does saved us a lot of time when dealing with the "mess" of the XML. Next time, before people start complaining the XML mess that the entire project team is creating, I think it's the projects' architect team’s responsibility (Spring Architect, maybe? :-) to set it off so it WON'T get into that kind of mess at all.
  35. Re: What XML mess ?[ Go to top ]

    ...We can include/exclude an AOP Performance test reporting capability in 5 sec. (JETM, http://jetm.void.fm/ => IMHO, this is the best design/implementation for the Spring AOP, using Maven goal, w/o one line of codes or XML change, we can easily apply the AOP performance test output by adding or removing some jars.)
    You might want to check out the following article and blog entry for a comprehensive performance management and runtime diagnostic solution for Spring and many other Java technologies and platforms. Spring Tracing with JXInsight http://www.jinspired.com/products/jxinsight/springtracing.html This blog entry describes the integration of JXInsight with the Oracle Depot article mentioned in Rod's year highlights. http://blog.jinspired.com/?p=29 Kind regards, William Louth JXInsight Product Architect JInspired "Java EE tuning, testing, tracing, and monitoring with JXInsight" http://www.jinspired.com
  36. Re: What XML mess ?[ Go to top ]

    ...We can include/exclude an AOP Performance test reporting capability in 5 sec. (JETM, http://jetm.void.fm/ => IMHO, this is the best design/implementation for the Spring AOP, using Maven goal, w/o one line of codes or XML change, we can easily apply the AOP performance test output by adding or removing some jars.)


    You might want to check out the following article and blog entry for a comprehensive performance management and runtime diagnostic solution for Spring and many other Java technologies and platforms.

    Spring Tracing with JXInsight
    http://www.jinspired.com/products/jxinsight/springtracing.html

    This blog entry describes the integration of JXInsight with the Oracle Depot article mentioned in Rod's year highlights.
    http://blog.jinspired.com/?p=29

    Kind regards,

    William Louth
    JXInsight Product Architect
    JInspired

    "Java EE tuning, testing, tracing, and monitoring with JXInsight"
    http://www.jinspired.com
    JETM is free and open source (I have nothing to do with their developer teams. Just want to say thanks to them.) I know that with AOP, there are a lot more can be done. I can see you have a much comprehensive solution, if and only if I can convince my boss to pay for that. ;)
  37. Re: What XML mess ?[ Go to top ]

    Working in unmanagable mess of XML configurations makes us "unhappy", as would some zealot say.


    We have been using Spring Framework for the past two years in the development a consumer portal (4M - 6 M users base) and it saves us so much effort when we try to rewrite the site and bring new enhancements into the new 100% Spring enabled code base easily. We actually retired a lot of our own internal frameworks and configure almost all of our applications inside of Spring XML.

    Just to name a few here about what kind of activities we can do quickly now,

    1. We can add an MBean operation in 5 sec.

    2. We can configure a cron job type of timer in 5 sec.

    3. We can include/exclude an AOP Performance test reporting capability in 5 sec. (JETM, http://jetm.void.fm/ => IMHO, this is the best design/implementation for the Spring AOP, using Maven goal, w/o one line of codes or XML change, we can easily apply the AOP performance test output by adding or removing some jars.)

    etc,....

    Of course Spring Framework alone can not be a silver bullet. We use Maven (1.0.2) and carefully divide our contexts into smaller projects so we can clearly identify the dependency among them. We also define our domain Model using AndroMDA (UML) so we can apply template and behavior to our domain model easily. (Most of our backend are MQ & Web Services now, so I can't really comment on the Hibernate & Transaction related parts.)

    In our Web Tier project, we only have about 50 Java files where they have to be tied to the App Server. Everything else is in the individual Eclipse projects (jars).

    When developers get used to them, they become very productive in less than one week. (Nodaway, we have so many off-shore resources just come and go.) We are not even using any Spring Plug-in in Eclipse. Developers know how to search for the Beans in the XML even though they might be in different projects. 95% of our beans are singletons so we know there should be only one Bean definition in the entire XML space. We also have defined clear patterns for the names of the Java codes (from different middle-tier layers) and the naming patterns of the XML contexts. All the above does saved us a lot of time when dealing with the "mess" of the XML.

    Next time, before people start complaining the XML mess that the entire project team is creating, I think it's the projects' architect team’s responsibility (Spring Architect, maybe? :-) to set it off so it WON'T get into that kind of mess at all.
    +1 You experience echos my own. As we enhance our framework, based on Spring, things like you describe come easy. Want to add a scheduled job? No problem. Want to cache any object, at any layer? Done. Email based error notifications for exceptions. Easy. We also have things like profiling and security out of the box. Also, things like the Spring plugin for Idea coupled with Idea's inhouse Spring support makes the XML a no-brainer. By using reasonable conventions and educating people on them, the XML becomes fairly predictable.
  38. Re: What XML mess ?[ Go to top ]

    We have been using Spring Framework for the past two years in the development a consumer portal (4M - 6 M users base) and it saves us so much effort when we try to rewrite the site and bring new enhancements into the new 100% Spring enabled code base easily.
    Talk about what you don't need, then we will all see the pain it's to use Spring when all you need is something very simple. What I mean is, look at Hibernate (I know, nothing to do with Spring at all, just an example). Is it really worth the trouble when all you need is JDBC because all what you will ever do is to work with Oracle? Your client won't change DBs every year, will he? You can very easily make queries with one line of code, with the proper abstractions. There are even some utililities such as Jakarta DBUtils that help with that. Now look at IoC, is Java really suited for this kind of thing? Shouldn't you use some other language that has the proper features instead of masochistically use Java for that? Doesn't IoC force you to go out of your way (bad class design + useless setters/getters) when you don't actually need it? Isn't it true that you will never be able to get rid of dependencies, since they will all be in the XML? Wasn't IoC overhyped? Wouldn't a well designed system with well defined abstractions and dependencies be preferrable to IoC? Do people pass most of their time building factories and proxies instead of solving the client's problems? Now look at AOP, doesn't it introduce design problems such as "never be sure what will happen at some place"? Does it remind you of the "goto" statement? I would rather have a new language on the JVM with the proper features than use Java for it. Spring is way too much trouble. Maybe for really big projects with some very specific requirement that pays off, but anything other than that it will be a pain. I am not a Ruby fan, but they have point. Some Java developers ARE crazy.
  39. Re: What XML mess ?[ Go to top ]

    Well, Spring enables me to write queries in one line of code. With Spring and Hibernate, I get CRUD and getAll(get all of a paricular domain) out of the box. But I get all the Hibernate stuff with this. In fact, in quite a few cases, our SQL queries become much simpler BECAUSE of how the objects are mapped. Maybe its me, but Hibernate is pretty simple. If you have simple needs, its easy. If you have more complex, it works well for that also. In addition, peple use Spring so they don't have to spend time building factories and proxies. Our customers and testers have all commented on the quality of our code because tools like Spring and Hibernate allow us to focus on the core code. Across the board, our software is easier to maintain, faster, more reliable, more robust, and more feature laden. We can put out more features because of the leveraging of Spring and Hibernate. As for your question about AOP? You are mistaken. It is nothing like a goto. You've clearly never used AOP. I've used the same Spring based framework on projects as small as two pages and in fact used those same projects for new people. The problem is that some Java developers are crazy, but that all Java developers are not created equal. Some are more skillful than others. It takes skill to use a particular technology correctly and to teach others.
  40. Re: What XML mess ?[ Go to top ]

    Well, Spring enables me to write queries in one line of code. With Spring and Hibernate, I get CRUD and getAll(get all of a paricular domain) out of the box.
    I know one killer technology that allows you to query data very easily, it's called SQL. Why, for everything that's sacred, some Java developers consider SQL bad? Is it too hard for them to understand it?
    But I get all the Hibernate stuff with this. In fact, in quite a few cases, our SQL queries become much simpler BECAUSE of how the objects are mapped.
    The DDL will be the same. What are the advantages? You will do the same thing as everyone else BUT your software will be dependent on Hibernate + complexity + maintenance overhead.
    In addition, peple use Spring so they don't have to spend time building factories and proxies.
    Are factories and proxies that much used? The way Spring people talk it seems developers spend 90% of their time building factories.
    Our customers and testers have all commented on the quality of our code because tools like Spring and Hibernate allow us to focus on the core code.
    I seriously doubt it. And I don't see the connection of cause and effect between using Spring and the quality of your code. Your clients shouldn't care about the quality of your code, they should care only if it works or not and if it's expensive or not to update.
    Across the board, our software is easier to maintain, faster, more reliable, more robust, and more feature laden. We can put out more features because of the leveraging of Spring and Hibernate.
    Haha, the standard Spring marketing. This is the problem with Spring people, they believe they are the only ones in the face of the Earth that build "robust, reliable, faster (sic!), etc, etc, etc" code. Does it remind you of some zealots that claim to be happy? Anyway, if you could come up with connections of cause and effect between all those things I could buy it. But apparently Spring developers never got that far.
    As for your question about AOP? You are mistaken. It is nothing like a goto. You've clearly never used AOP.
    Really? AOP turns the code in nothing more than a wish list. There's no way of guaranteeing what is going to happen in a certain point by just looking at the code. But don't believe in me, google a little and you will find critiques about it, like this one: http://www.infosun.fmi.uni-passau.de/st/papers/EIWAS04/stoerzer04aop_harmful.pdf
    Some are more skillful than others. It takes skill to use a particular technology correctly and to teach others.
    The standard Spring finale: snob everyone else and pose yourself as some sort of über-geek. Everyone that disagrees with you is clearly not as skillful.
  41. SQL? What next, assembly?[ Go to top ]

    I know one killer technology that allows you to query data very easily, it's called SQL. Why, for everything that's sacred, some Java developers consider SQL bad? Is it too hard for them to understand it?
    The high degrees of coupling (e.g. using SQL directly interleaved with application logic) causes a high level of fragility. IMHO (and from my own experience) its use in application coding is a "worst practice" for large-scale projects and/or large teams. In a DAO layer, it is acceptable, but then why wouldn't you just use a higher level tool (including something like Hibernate/KODO/Toplink)? Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  42. Yeahhh !!! assembly[ Go to top ]

    Why some Java developers consider assembly bad? Why them use things such "if" or "for" if them can use a single instruction like "mov". I think them deserve the java instructions hell. :) Thiago: Do you know the word "abstraction"? Have you ever listened about OOP? Do you have a clue of what domain driven design is? I don't think so. Flavio
  43. Re: What XML mess ?[ Go to top ]

    Really? AOP turns the code in nothing more than a wish list. There's no way of guaranteeing what is going to happen in a certain point by just looking at the code. But don't believe in me, google a little and you will find critiques about it, like this one:

    http://www.infosun.fmi.uni-passau.de/st/papers/EIWAS04/stoerzer04aop_harmful.pdf

    So if someone post a PDF on the web then it's truth of all? IMO, using AOP as a goto will only get yourself into trouble. I totally agree it's a misusage of this concept. However, because the food may choke you to death when you try to swallow it without chewing, thou shall never try to eat any? We are using AOP to perform performance test any beans we defined in the Context. It gives us all the performance result w/o any Java coding. And the XML configuration can be active/inactive depending whether the jar is there or not. With a simple MBean wiring from Spring, we can turn on / off this feature to all JVMs by simply using a jacl script to trigger the Performance Test Bean. My boss is really happy because I can spend more time to work on more critical business logic related issues other than re-inventing the wheels again and again. We have done all that before by following the JMX implementation in WebSphere where you have to write other XMLs, Java codes and worrying about the classpath for those XMLs. Then using Apache StopWatch to get the milliseconds from all the Java codes (defining the list in another property files or XML) and output to a performance manager as a session listeners, where it will spit out performance test data every 10 minutes... If you don't need any of this, you are lucky (or unlucky?) because no one really cares about those on your site. Or maybe you are very good at creating them all by yourself so you can do all the above using your own implementation in 10 minutes (using whatever other technology you can get). I think your parents will be very proud of you. :-)
  44. Re: What XML mess ?[ Go to top ]

    My boss is really happy because I can spend more time to work on more critical business logic related issues other than re-inventing the wheels again and again.
    I think you will find that there are many products on the market that would not have you re-inventing the wheel at least with regard to normal performance test management. Admittedly some are over priced for what you get in terms of analysis and visualization (red circle = bad, green circle = good) but they all at least integrate with standard platforms and technologies and can be used across the complete application life cycle and not just in development providing much more resource consumption analysis than an apache stopwatch. Over the next year we might see an increase in the adoption of AOP but with this comes the strong likelihood of substantial re-development (inefficiency on a large scale) of the same cross cutting concern - whats new!. We will have at least one new logging and tracing framework released once a hour as developers look to use AOP to solve the same problem again and again whilst ignoring the existing knowledge, standards, and effective solutions available in the industry. This will clearly be the case because this is in general the comfort and play zone for most developers. The growing adoption of AOP faces many challenges including the side effects of various different AOP solutions running in the same JVM all injecting concerns without little co-ordination across each concern & introduction mechanism in ensuring correctness and efficiency of the overall solution. This can already be seen today with reports of code level profilers crashing when profiling AOP enabled applications. I know that one of the biggest vendors of performance management solutions has problems providing a solution for applications using Hibernate CGLIB proxies. To be honest it is a hard problem to solve but if AOP is to have a chance it must be supported natively inside the JVM runtime and meta layers instead of via byte code instrumentation libraries that step on each other once to often in a production system. Regards, William Louth JXInsight Product Architect JInspired "Java EE tuning, testing, tracing, and monitoring with JXInsight" http://www.jinspired.com
  45. Thanks for the info.[ Go to top ]

    I'm glad to learn this new inside story regarding AOP as myself is also considered new to this concept. That's exactly why we are approaching to it very slowly and carefully. (We still won't let those AOP jars into our production systems for now.) It's not really Spring only related topic here. :-)
  46. Re: What XML mess ?[ Go to top ]

    Well, Spring enables me to write queries in one line of code. With Spring and Hibernate, I get CRUD and getAll(get all of a paricular domain) out of the box.


    I know one killer technology that allows you to query data very easily, it's called SQL. Why, for everything that's sacred, some Java developers consider SQL bad? Is it too hard for them to understand it?

    For some *developers*, SQL could be a trial. However, you would be hard pressed to use Hibernate and *not* understand SQL. So, I would submit that perhaps you understand SQL and don't understand Hibernate. That's okay, but your understanding(or potential lack of) doesn't mean that others can't use a particular technology easily and effectively.
    But I get all the Hibernate stuff with this. In fact, in quite a few cases, our SQL queries become much simpler BECAUSE of how the objects are mapped.


    The DDL will be the same. What are the advantages? You will do the same thing as everyone else BUT your software will be dependent on Hibernate + complexity + maintenance overhead.

    Many advantages. See, database access is more than just SQL. I'm not going to get into object graphs, caching, lazy instantiation, criteria API, or all that other stuff Hibernate does in addition to SQL, but it is significant. Perhaps a visit to the Hibernate site is in order. Also, since I'm here and you are not, you really aren't in any position to comment on how complex or maintanable my software is. The only ones who can comment are me, the other developers, our customers, and my management. Since you don't fall into any of those slots, who care what the terminally wrong think?
    In addition, peple use Spring so they don't have to spend time building factories and proxies.


    Are factories and proxies that much used? The way Spring people talk it seems developers spend 90% of their time building factories.

    No, that's what you inferred. It would probably more accurate to say that 90% of developers should use a factory, so why reinvent the wheel?
    Our customers and testers have all commented on the quality of our code because tools like Spring and Hibernate allow us to focus on the core code.


    I seriously doubt it. And I don't see the connection of cause and effect between using Spring and the quality of your code. Your clients shouldn't care about the quality of your code, they should care only if it works or not and if it's expensive or not to update.

    You doubt it? Seriously? I'm sorry, but which one of our customers or testers have you spoken to? I mean, I must have missed you here at work yesterday, because it sounds like you must have access to our people and software. Also, unlike whatever you do, I guess, our customers DO care about the quality of the code, because that affects whether it works and how expensive it is. Perhaps this is because we actually explain this to them.
    Across the board, our software is easier to maintain, faster, more reliable, more robust, and more feature laden. We can put out more features because of the leveraging of Spring and Hibernate.


    Haha, the standard Spring marketing. This is the problem with Spring people, they believe they are the only ones in the face of the Earth that build "robust, reliable, faster (sic!), etc, etc, etc" code. Does it remind you of some zealots that claim to be happy?

    Anyway, if you could come up with connections of cause and effect between all those things I could buy it. But apparently Spring developers never got that far.

    Again, that is what you infer. Spring is but one tool in my toolkit. I would say the same thing about Hibernate, OSCache, Jakarta, etc... The problem is that you have some kind of dysfunction concerning Spring that your thinking is clouded. Perhaps, jealousy. Regardless, this kind of leverage has allowed us to consistenly meet or exceed our customer expectations even under the burdern of tight deadlines.
    As for your question about AOP? You are mistaken. It is nothing like a goto. You've clearly never used AOP.


    Really? AOP turns the code in nothing more than a wish list. There's no way of guaranteeing what is going to happen in a certain point by just looking at the code. But don't believe in me, google a little and you will find critiques about it, like this one:

    Well, if you want(or need) such a guarantee, the whole OO paradigm or just using any third-party software must seem pretty daunting. And no, I don't believe you. I have the benefit of DIRECT EXPERIENCE, and generally, that is more reliable than any google search. Unlike you, I guess, I can draw my own conclusions when so compelled. I've been using AOP since mid-05, and have written my own proxies before that. Not as flexible as Spring, but enough to understand what Spring's doing. Now, using AOP, we have Security, profiling, caching, email notification of exceptions, and other items in very clean code. All those items are completed decoupled, easily modified, added, or removed. Success trumps your article everyday of the week.
    The standard Spring finale: snob everyone else and pose yourself as some sort of über-geek.

    Everyone that disagrees with you is clearly not as skillful.

    Not at all. In fact, I am routinely thankful for the nerdlingers who put out all this stuff! Where would we be without them? If you are saying that Spring(and Hibernate) is hard, and I say they are not, then there is clearly a difference between us. I don't lay claim to any great insight, any superior skill. In fact, I am lazy, impatient, and stubborn. I am also pretty stingy with my time because I want to enjoy the fruits of my labor. This is why, for example, I didn't care for Toplink. It seemed to make my life harder. Hibernate made it easier. So did Spring.
  47. Re: What XML mess ?[ Go to top ]

    As for your question about AOP? You are mistaken. It is nothing like a goto. You've clearly never used AOP.
    Please refer to the following: http://www.infosun.fmi.uni-passau.de/st/papers/EIWAS04/stoerzer04aop_harmful.pdf Tom
  48. Re: What XML mess ?[ Go to top ]

    As for your question about AOP? You are mistaken. It is nothing like a goto. You've clearly never used AOP.


    Please refer to the following:

    http://www.infosun.fmi.uni-passau.de/st/papers/EIWAS04/stoerzer04aop_harmful.pdf

    Tom
    Shrug. http://members.cox.net/davehanson/weirdworld/milk.htm Stop drinking milk!!
  49. Spring?[ Go to top ]

    Spring? We have winter now! :) OSGi would be fine. Spring needs to become a standard (a specified one).
  50. Hi All, I like Spring, but IMO it largely solves a problem of our own making. My view is that Spring took of because people wanted a loosely coupled late-bound component architecture without the overhead of an heavy-weight aplication server. Spring delivers this for Java programmers and does it well IMO. But why did we have heavy-weight containers in the first place? Why is late-binding of Java objects such a problem? It all stems back to C++, and it spawned component models: COM and CORBA. The lack of a dynamic message send in C++ led to the need for complex runtimes inorder to bind together objects after compile time. Along with the virtual function call, Java inherited this legacy from C++ and largely suffers the same problem, hence EJB's were mostly a Java re-implementation of CORBA. There are C based OO languages that avoided these pitfalls, for example Objective-C. Objective-C retained the OO messaging semantics of Smalltalk, at the cost of a little indirection at runtime. As a consequnce it lead to the extremely successful component model used in NextStep and now present in the Mac OS X user interface as Cocoa. Loose coupling and late-binding is what Spring is all about IMO. These architectual qualities are more easily delivered using a dynamic OO language with late-bound, polymorphic message sends (instead of early-bound virtual function calls). This is why I see Spring as a stepping stone along the path to fully dynamic architectures, and I see Rails and Ruby picking up where Spring and Java hit their inherent limits. Paul.
  51. I'm fleeing to Python and Django. ;-)
  52. I like Spring, but IMO it largely solves a problem of our own making. My view is that Spring took of because people wanted a loosely coupled late-bound component architecture without the overhead of an heavy-weight aplication server.
    I may be mistaken, but I have always assumed you have argued that Java application servers don't provide a loosely coupled late-bound component architecture; so Swing can't logically be an alternative to them for providing this. Also, I am sure there are a considerable number of developers like me who use Spring simply because it is a clean way to do IoC and configuration - nothing at all to do with late binding.
    This is why I see Spring as a stepping stone along the path to fully dynamic architectures, and I see Rails and Ruby picking up where Spring and Java hit their inherent limits.

    Paul.
    You don't need to resort to those. You don't need to lose performance, stability or tight integration with Java. Spring is evolving, and configuration can be done using dynamic languages on the JVM - especially Groovy. That way those who want to use dynamic languages can do so while avoiding the considerable inherent limits of Ruby and Rails.
  53. I like Spring, but IMO it largely solves a problem of our own making. My view is that Spring took of because people wanted a loosely coupled late-bound component architecture without the overhead of an heavy-weight aplication server.


    I may be mistaken, but I have always assumed you have argued that Java application servers don't provide a loosely coupled late-bound component architecture; so Swing can't logically be an alternative to them for providing this.

    Also, I am sure there are a considerable number of developers like me who use Spring simply because it is a clean way to do IoC and configuration - nothing at all to do with late binding.

    Indeed. In fact, I started using Spring with the original intent of just replace configuration files and my original factories. However, since this proved to be so smooth, I then moved to replace my own custom Dynamic proxies and utilized Springs Hibernate integration combined with its declarative transaction support. I would argue that the reasons people use Spring are: 1) Declarative Transaction support 2) Spring AOP 3) IOC 4) Persistence integration support 5) Other tool support. I would submit that very, very few see Spring as a bridge to Ruby or Rails. In fact, I would submit that Dynamic language simulation wasn't and isn't on the radar for most Java users. Currently, I don't think the dynamic languages are compelling enough.
  54. I like Spring, but IMO it largely solves a problem of our own making. My view is that Spring took of because people wanted a loosely coupled late-bound component architecture without the overhead of an heavy-weight aplication server.


    I may be mistaken, but I have always assumed you have argued that Java application servers don't provide a loosely coupled late-bound component architecture; so Swing can't logically be an alternative to them for providing this.

    Also, I am sure there are a considerable number of developers like me who use Spring simply because it is a clean way to do IoC and configuration - nothing at all to do with late binding.



    Indeed. In fact, I started using Spring with the original intent of just replace configuration files and my original factories. However, since this proved to be so smooth, I then moved to replace my own custom Dynamic proxies and utilized Springs Hibernate integration combined with its declarative transaction support.

    I would argue that the reasons people use Spring are:
    1) Declarative Transaction support
    2) Spring AOP
    3) IOC
    4) Persistence integration support
    5) Other tool support.

    I would submit that very, very few see Spring as a bridge to Ruby or Rails. In fact, I would submit that Dynamic language simulation wasn't and isn't on the radar for most Java users.

    Currently, I don't think the dynamic languages are compelling enough.
    Hi Steve, I was trying to focus on the problem. As so often we tend to focus on the technology and the soluton. You found that Spring was so smooth because it solved problems you didn't know you had. In the same vien dynamic languages solve problems that many static language programmers do not appreciate they have, until they see a better solution. Java has an inherent limitation steming from static compile time defined virtual function calls. This is the key point, objects are inherently loosely coupled in a dynamic language through the use of a message send. This difference opens up a whole new realm of possibilities. Paul.
  55. Hi Steve,

    I was trying to focus on the problem. As so often we tend to focus on the technology and the solution
    Firstly, you are replying to the wrong person, secondly I think you are way off track here. I really can't see any significant use of Spring as a way of providing dynamic language features; this seems a rather odd perspective on things. After all, if Java developers want to use dynamic language features, why bother with Spring to do this when there are already fine solutions for this on the JVM - BeanShell, Groovy, JRuby, Jython and so on? Spring is not about that kind of thing; indeed, it can be used entirely from within statically compiled non-dynamic Java; XML is simply considered by many of (though not all!) us a simpler way to describe the configuration.
  56. Limitations[ Go to top ]

    Java has an inherent limitation steming from static compile time defined virtual function calls.
    I never thought of an API as a limitation. I for one like to get compile-time errors. When I need to pass messages not defined at comile-time, I use a Messaging API.
    You found that Spring was so smooth because it solved problems you didn't know you had.
    I've experienced Spring patching up problems some developer has created himself instead of addressing the original problem (take your BeanFactory and it's runtime errors out of my application, please).
  57. Re: Limitations[ Go to top ]

    Java has an inherent limitation steming from static compile time defined virtual function calls.

    I never thought of an API as a limitation. I for one like to get compile-time errors.

    When I need to pass messages not defined at comile-time, I use a Messaging API.
    HI Kofi, A static API can be a limitation, especially when you are trying to bind together objects after they have been compiled. The same issue occurs with distribited objects and SOA. The REST approach avoids the use of a static API (new verbs), for exactly the same reasons I express here . See this thread on InfoQ: http://www.infoq.com/articles/separation-of-concerns As for the compiler doing the checking, you can still have this without coupling your interface with your implementation. Take a look at Strongtalk and it's type system: http://www.strongtalk.org/ BTW with Java interfaces as used in Spring, there is no compile-time check. If your Spring bean factory instantiates an object with the wrong interface, then the only time you will find out about it is at runtime. Paul.
  58. I like Spring, but IMO it largely solves a problem of our own making. My view is that Spring took of because people wanted a loosely coupled late-bound component architecture without the overhead of an heavy-weight aplication server.


    I may be mistaken, but I have always assumed you have argued that Java application servers don't provide a loosely coupled late-bound component architecture; so Swing can't logically be an alternative to them for providing this.

    Also, I am sure there are a considerable number of developers like me who use Spring simply because it is a clean way to do IoC and configuration - nothing at all to do with late binding.

    What is IoC without late-binding? All that XML configuration, or Groovy configuration or JRuby configuration is about binding objects together after compile time.
    This is why I see Spring as a stepping stone along the path to fully dynamic architectures, and I see Rails and Ruby picking up where Spring and Java hit their inherent limits.

    Paul.


    You don't need to resort to those. You don't need to lose performance, stability or tight integration with Java. Spring is evolving, and configuration can be done using dynamic languages on the JVM - especially Groovy. That way those who want to use dynamic languages can do so while avoiding the considerable inherent limits of Ruby and Rails.
    Yes. Agreed. Ruby or Rails is not the last word in dynamic languages, but I was talking about architectural patterns and for this I believe it does show what can be done with plain old objects, domain driven design, message sends and runtime binding. Paul.

  59. What is IoC without late-binding? All that XML configuration, or Groovy configuration or JRuby configuration is about binding objects together after compile time.
    You are confusing concepts here. There are long-established IoC frameworks in pure Java that involve statically compiled code - nothing dynamic or late bound at all. Check out PicoContainer. Just because Spring can do IoC, and Spring's approach to IoC is at runtime if you use XML, does not mean that IoC has to involve late binding. That is not the point of IoC.
    This is why I see Spring as a stepping stone along the path to fully dynamic architectures, and I see Rails and Ruby picking up where Spring and Java hit their inherent limits.
    Sorry, but I just can't see that.

  60. What is IoC without late-binding? All that XML configuration, or Groovy configuration or JRuby configuration is about binding objects together after compile time.


    You are confusing concepts here. There are long-established IoC frameworks in pure Java that involve statically compiled code - nothing dynamic or late bound at all. Check out PicoContainer.

    Just because Spring can do IoC, and Spring's approach to IoC is at runtime if you use XML, does not mean that IoC has to involve late binding. That is not the point of IoC.

    Hi Steve, No confusion, I used Picocontainer before I came across Spring. It would be nice to hear from Rod Johnson, but if you read his book on J2EE without EJB's you can clearly see what inspired spring. As for IoC, it is a design pattern than has existed long before Java even. Smalltalk programmers have been using it for years as an object creational pattern. IoC containers though like Picocontainer and Spring (and Xworks, Hivemind etc), tie the basic IoC object creational pattern with late binding, etiher through scripting or configuration files.
    This is why I see Spring as a stepping stone along the path to fully dynamic architectures, and I see Rails and Ruby picking up where Spring and Java hit their inherent limits.


    Sorry, but I just can't see that.
    Fine, many others do. Paul.
  61. IoC containers though like Picocontainer and Spring (and Xworks, Hivemind etc), tie the basic IoC object creational pattern with late binding, etiher through scripting or configuration files.
    Standard use of PicoContainer does not use either scripting or configuration files. As the documentation says: "The components are assembled in the container using a simple Java API that is similar to an intelligent hash map utilizing the type of its values." And as I said, Spring can be used entirely from pure Java code with no dynamic nature at all. To imply that IoC necessarily involves or implies late binding is just plain wrong, and a misunderstanding of what IoC is.
  62. To imply that IoC necessarily involves or implies late binding is just plain wrong, and a misunderstanding of what IoC is.
    Hi Steve, To imply that IoC necessarily involves or implies the use of an IoC container like Spring or Picocontainer is just plain wrong, and a misunderstanding of what IoC is. Paul.
  63. To imply that IoC necessarily involves or implies late binding is just plain wrong, and a misunderstanding of what IoC is.


    Hi Steve,
    To imply that IoC necessarily involves or implies the use of an IoC container like Spring or Picocontainer is just plain wrong, and a misunderstanding of what IoC is.

    Paul.
    Where did I say that IoC implies use of PicoContainer or Spring? I am only using those to show that IoC can be done without any use of dynamic features, and without any late binding, therefore illustrating that those are not features that have to be associated with IoC, that IoC works perfectly well at compile time, in order to refute this:
    What is IoC without late-binding? All that XML configuration, or Groovy configuration or JRuby configuration is about binding objects together after compile time.
    Of course, most Spring configuration (by whatever mechanism) ends up packaged into Jars, so the bindings are fixed at build time (although not technically at compile time).
  64. To imply that IoC necessarily involves or implies late binding is just plain wrong, and a misunderstanding of what IoC is.


    Hi Steve,
    To imply that IoC necessarily involves or implies the use of an IoC container like Spring or Picocontainer is just plain wrong, and a misunderstanding of what IoC is.

    Paul.


    Where did I say that IoC implies use of PicoContainer or Spring?

    I am only using those to show that IoC can be done without any use of dynamic features, and without any late binding, therefore illustrating that those are not features that have to be associated with IoC, that IoC works perfectly well at compile time, in order to refute this:

    What is IoC without late-binding? All that XML configuration, or Groovy configuration or JRuby configuration is about binding objects together after compile time.


    Of course, most Spring configuration (by whatever mechanism) ends up packaged into Jars, so the bindings are fixed at build time (although not technically at compile time).
    Hi Steve, This is exactly why I continue to post my non-conformist views on TSS. First there is an idea, then it gets a marketing label, and from there it gains a whole life of it's own. Spring is a tool, a good tool at that, but it is not an ends in itself. The IoC (or DI) object creational pattern constructs an object by injecting external dependencies at object creation time. With a dynamic language the interface (Protocol) of the external objects are inherently seperate from their implmentation (Class). For Java though, should you wish to reconfigure your target object to use different objects you need to declare an Interface and Inject a given implementation at runtime. So whether you use Java, XML or whatever, IoC with Spring binds external objects to a target object to create an object graph at runtime. This is late-binding. How you decide to deploy is up to you, but with the use of Interfaces and an IoC container and a configuration file, you could choose to deploy with several jars, allowing you to change application component implementations at runtime. Given that for most web apps there is seldom little need to do this, then configuration with Java is totally appropriate, but it is still late-bound, with the associated loose coupling. BTW, before the label IoC became popular, people use to configure application components in a similar way, the only thing is back then it was done in a method called "init," or "applicationStartup" etc. Paul.
  65. This is exactly why I continue to post my non-conformist views on TSS. First there is an idea, then it gets a marketing label, and from there it gains a whole life of it's own.
    Non conformist views are fine; but they need to be based on facts. So far you have said, basically, that IoC 'is nothing without late binding', that "IoC containers like PicoContainer..." 'work through configuration or scripting', and you have said that I stated that 'IoC implied use of Spring or PicoContainer'. All wrong. All IoC does is to avoid close coupling. The binding is no more 'late' than doing Class.forName(). (Which is somewhat late-ish, but hardly in the dynamic language sense). IoC can be part of a larger, more flexible framework, sure, but that is all that IoC does. We have to be careful with terms, as 'late binding' is rather like 'object oriented': very broad and loosely applied. In some senses, people could describe some C++ code as late bound. I am assuming the meaning of binding things specified at runtime. By that definition, it is an extreme point of view to call this: Class aClass = MyClass.class; Class myClass = aClass.newInstance(); thing.setInstance(myClass); late binding - but that is basically the way that IoC frameworks like PicoContainer work.
    So whether you use Java, XML or whatever, IoC with Spring binds external objects to a target object to create an object graph at runtime.
    If you want to turn every thread you participate in into a debate about how Java is so bad because we didn't listen to Alan Kay (to exaggerate somewhat), you are going to have to find the right 'angle' to do it with. Claiming that IoC necessarily involves 'late binding' in the dynamic language sense isn't such an angle. To claim that IoC is about late binding because of the way most implementations specific the classes to be bound is about as appropriate as claiming that Java is a logic programming language because it includes the keyword 'if'...
  66. This is exactly why I continue to post my non-conformist views on TSS. First there is an idea, then it gets a marketing label, and from there it gains a whole life of it's own.


    Non conformist views are fine; but they need to be based on facts. So far you have said, basically, that IoC 'is nothing without late binding', that "IoC containers like PicoContainer..." 'work through configuration or scripting', and you have said that I stated that 'IoC implied use of Spring or PicoContainer'. All wrong.

    All IoC does is to avoid close coupling. The binding is no more 'late' than doing Class.forName(). (Which is somewhat late-ish, but hardly in the dynamic language sense).

    IoC can be part of a larger, more flexible framework, sure, but that is all that IoC does.

    We have to be careful with terms, as 'late binding' is rather like 'object oriented': very broad and loosely applied. In some senses, people could describe some C++ code as late bound. I am assuming the meaning of binding things specified at runtime. By that definition, it is an extreme point of view to call this:


    Class aClass = MyClass.class;
    Class myClass = aClass.newInstance();
    thing.setInstance(myClass);


    late binding - but that is basically the way that IoC frameworks like PicoContainer work.

    So whether you use Java, XML or whatever, IoC with Spring binds external objects to a target object to create an object graph at runtime.


    If you want to turn every thread you participate in into a debate about how Java is so bad because we didn't listen to Alan Kay (to exaggerate somewhat), you are going to have to find the right 'angle' to do it with. Claiming that IoC necessarily involves 'late binding' in the dynamic language sense isn't such an angle.

    To claim that IoC is about late binding because of the way most implementations specific the classes to be bound is about as appropriate as claiming that Java is a logic programming language because it includes the keyword 'if'...
    Steve, You're wrong! I like Spring alot, I've said that more than once. As mentioned by other posters, what is going on here is your overinflated ego. My aim was to provide a different perspective, I believe I've done that. I'm done. Peace, Paul.
  67. You're wrong!
    Fine. In that case, in might have been productive to attempt to explain why.
    I like Spring alot, I've said that more than once.
    As far as I can tell, no-one has claimed you don't.
    As mentioned by other posters, what is going on here is your overinflated ego.
    I am really sorry you posted this. I have respect for your views in general, I just think you are way out here. If you want to disagree, challenge on facts.
    My aim was to provide a different perspective, I believe I've done that.
    A perspective based on a foundation of Spring as a general stepping stone to dynamic languages, and claim that IoC is founded on late binding is not based on much substance, at least in my view. If you are going to post a perspective which talks about Spring as a stepping stone to systems like Ruby on Rails because of the 'limitations of Spring and Java' on a forum like this, and with a topic like this, it is only reasonable to have it vigorously debated.
  68. Standard use of PicoContainer does not use either scripting or configuration files.

    As the documentation says:

    "The components are assembled in the container using a simple Java API that is similar to an intelligent hash map utilizing the type of its values."

    And as I said, Spring can be used entirely from pure Java code with no dynamic nature at all.

    To imply that IoC necessarily involves or implies late binding is just plain wrong, and a misunderstanding of what IoC is.
    I hesitate to dive into this maelstrom but here goes: My background: I was (might still be) a committer on NanoContainer. I developed the first cut of NanoContainer's AOP mechanism, and a scripted NanoAOP configuration mechanism via Groovy. I don't know if anything every came of that; I switched to using Spring when it became clear that is was becoming the dominant IoC framework and had developed a high quality implementation and good documentation. I also develop in Ruby and Rails. Here's why you don't really need IoC in languages like Ruby: IoC basically solves the 'new' problem. In languages like Java new is a built in operator that you can't override. It's not polymorphic. Take this code: date = new Date(); That line ties my code to the concrete class java.util.Date, and to the implementation of the Date default constructor. I can't change that without changing my code. That code is hard to test. If only I could change the behavior of 'new'! In Java you can't. IoC works around that problem (that 'new' is not polymorphic) by flip-flopping the dependency and injecting in the concrete instance, as we all know. There are costs though: you have to anticipate the need for this flexibility up front (by not using the 'new' operator), more indirection which can make the code harder to follow, and more configuration files. Still it's a brilliant workaround for a language limitation. In Ruby (and other languages) however new is a polymorphic method of class Class, and classes are first class objects. So in Ruby you write this: date = Date.new Contrary to appearances that code does not tie me to a particular class or constructor. If I need to mock out the current date for unit testing I can do so either by overriding the factory method Date.new in my test, or more commonly by assigning the constant 'Date' to a new mock date class. The point is that in Ruby you don't need IoC to change the behavior of new. It's not really a static vs. dynamic thing but more an issue of how deep OO goes in the language. Of course this sort of thing scares the bejeezus out of died in the wool Java programmers. But programming to an interface not a concrete implementation shouldn't be scary. You're sending messages to encapsulated objects, not depending or caring about how or even when they're implemented. If you can deal with the fact that Spring can dynamically swap out implementations then Ruby shouldn't scare you that much. Once you start doing IoC you've lost much of the benefit of static typing anyway. If you want to verify the correctness of your code (and you should!), write tests. (I do realize that Spring is much more than just an IoC framework. It bundles together a whole slew of technologies into one coherent whole, like Rails. That's valuable with or without IoC. )
  69. Hi Stephen,
    I hesitate to dive into this maelstrom but here goes:
    Why hesitate? I know that TSS is not the most intellectual of forums, but it is main stream. We live in a sound bite culture. Many people do not read books, how many people read white papers? Infact how many people bother to write papers knowadays? Most people come to this stuff through a 10 minute tutorial on the web. If we chose to remain silent, then many of the best ideas (like Spring), will become diluted and skewed. I remember a project I worked on with Java programmers who did not apreciate the issues. I introduced Spring and you should have seen the abuse they were trying to put it to. People just don't know/understand this stuff. Great post! Paul.
  70. IoC works around that problem (that 'new' is not polymorphic) by flip-flopping the dependency and injecting in the concrete instance, as we all know. There are costs though: you have to anticipate the need for this flexibility up front (by not using the 'new' operator), more indirection which can make the code harder to follow, and more configuration files. Still it's a brilliant workaround for a language limitation.
    It is still not dynamic run-time late binding, is it? It is simply a neat method of decoupling of dependencies - simply taking out explicit object creation from users code. I apologise if this seemed like a 'maelstrom' - I am just after clarity, and when IoC using explicit class names in Java code is pitched as being any way similar to the kind of late binding availabile in Ruby or Smalltalk, I think that is possibly confusing things. Just my view....
  71. Spring and XML configuration[ Go to top ]

    I'm really getting tired with people talking about Spring's xml configuration files and how they can become very messy. As it stands there are alternatives to configurations files e.g. Annotations and Java Configuration files. Using the "Spring uses XML files" as an argument for not adopting Spring is no longer valid in my own opinion. Yes config files can get messy but so can application code (without spring). Its a matter of proper design. If you design your application properly and define your config file properly you won't get the messiness. Spring offers too much in terms of productivity and ease of development to ignore. I have been developing Spring applications for nearly 2 years now and I am fully satisfied with what it can offer. I am looking forward to when Spring becomes a standard in the J2EE arena.
  72. Spring, XML, and standards[ Go to top ]

    I'm really getting tired with people talking about Spring's xml configuration files and how they can become very messy. As it stands there are alternatives to configurations files e.g. Annotations and Java Configuration files.
    After getting into the spring thing only recently, my impression is that for most people Spring spells XML configuration. IIRC the documentation also promotes this. Let me add that I was completely baffled when I waded through this for the first time. Why in the world would people want to leave compile-time checking and near-perfect IDE support behind and program central parts of their application in XML? I cannot get it. Now, when I reveret to Java configuration (which I did), the next question is of course what exactly Spring - or any IoC container - buys me. I can easly code in terms of interfaces, implementations and configuration classes without using any framework/container AT ALL. Of course, at this point people will throw at me all the varied functionality Spring offers today: starting from declarative transactions, on to the Spring MVC web framework. However, even though all these may be useful toolsets, I like to first understand the essence of a concept and myke my judgement from there. Which brings me to the next point:
    I am looking forward to when Spring becomes a standard in the J2EE arena.
    which part of spring would you want to standardize, then? IoC is a concept that has already been introduced into JavaEE5, and will get more room if it works well (Fortunately, they do annotation-based IoC). Most of the other toolsets already have JavaEE counterparts as well. So what would be left? regards, Christian
  73. Re: Spring, XML, and standards[ Go to top ]

    Let me add that I was completely baffled when I waded through this for the first time. Why in the world would people want to leave compile-time checking and near-perfect IDE support behind and program central parts of their application in XML? I cannot get it.
    Now, when I reveret to Java configuration (which I did), the next question is of course what exactly Spring - or any IoC container - buys me. I can easly code in terms of interfaces, implementations and configuration classes without using any framework/container AT ALL.
    Good questions.
  74. Re: Spring, XML, and standards[ Go to top ]

    Let me add that I was completely baffled when I waded through this for the first time. Why in the world would people want to leave compile-time checking and near-perfect IDE support behind and program central parts of their application in XML? I cannot get it.
    Now, when I reveret to Java configuration (which I did), the next question is of course what exactly Spring - or any IoC container - buys me. I can easly code in terms of interfaces, implementations and configuration classes without using any framework/container AT ALL.

    Good questions.
    Very good question indeed. As I said before, people have been doing a similar thing using interfaces and runtime configuration in an "applicationInit" or "applicationStartup" method, no IoC Container involved. Granted, Spring makes this stuff a lot easier and has a lot of useful bits added on, but if people do not understand the why...! Paul.
  75. I don't get it either[ Go to top ]

    The only conclusion I can come up with is that most programmers don't think for themselves and are slaves to authority like sheep. Just look at Spring's crappy predecessors and their ultimate demise: EJB and Struts. Same audience, same sheep, same silver bullet. Seriously, creating web pages is easy. Why make things more complicated than they need to be?
  76. creating web page is easy ?[ Go to top ]

    The only conclusion I can come up with is that most programmers don't think for themselves and are slaves to authority like sheep. Just look at Spring's crappy predecessors and their ultimate demise: EJB and Struts. Same audience, same sheep, same silver bullet.

    Seriously, creating web pages is easy. Why make things more complicated than they need to be?
    Every one knows how to write HTML. My 1st grade daughter should have no problem to write the "Hello World" in any language and print it on the browser. What's the point? When we have to handle authentication using LDAP, encryption on web services, single-sign-on from 20 different clients, thousands of combination types of users who can get different type of links when they log in, when we need to deal with the downtime of the backend system or translate the data coming from different backend services (DB, MQ or Web Services) into the same domain model, when we have to deploy two releases per month and upgrade our GUI design every other year in addition to deal with different versions of browsers from different vendors...., you are telling me creating web pages is easy? Have your boss ever asked you to turn on/off a feature from your site for all the JVM in one shot w/o restarting the app server farms? Please help to tell my boss how easy it is to create the web page? (Don’t tell me you only deploy your web site to one single web server…) If you know any better technology that can help me to convince my boss that it can achieve all the above, reduce overall cost and get things done faster, easier, cheaper, more scalable and more maintainable, I am in all ears. Please don’t throw a blind statement here and just tell me creating a web page is easy.
  77. Your problems are web page development[ Go to top ]

    Meeting certain application requirements in a timely manner can be difficult and dealing with bad systems and development environments is certainly frustrating. Spring won't fix these problems. This is the so called essential complexity that can't be avoided regardless of the application framework, language, or tool you use. The best way to minimize the impact of these issues is through *good design*, which is essentially low coupling and high cohesion in your code. You can't buy design, plug it in, or click it away. That's your responsibility as developer. i.e. Spring's effect in alleviating your problems will be minimal if anything. (I'm essentially paraphrasing No Silver Bullets article, which I'm sure you realize) The simple part I was talking about is the part that Spring claims to fix. In my opinion, this part is essentially transferring data from the server to the browser. This part was never difficult and never really needed fixing. If anything it makes it more difficult simply because it adds layers, syntax, languages, and concepts that weren't needed previously without adding anything. As the parent poster realized, what have you gained for all your troubles that you couldn't have done before? Anyway to answer your question, tell your boss to hire smarter more talented developers and fire all the idiots you currently have since there are no more Silver Bullets.
  78. Re: I don't get it either[ Go to top ]

    The only conclusion I can come up with is that most programmers don't think for themselves and are slaves to authority like sheep. Just look at Spring's crappy predecessors and their ultimate demise: EJB and Struts. Same audience, same sheep, same silver bullet.

    Seriously, creating web pages is easy. Why make things more complicated than they need to be?
    And if all one had to do was create a web page, perhaps, I for one, would agree. However, that is one small part. I also have to integrate with other systems, create apps that are maintainable as well as quick to write, make them resuable, make them performant, etc... Sometimes other companies elect to take over, sometimes prototypes grow into production systems. If you needs are simple, then use something simple. Others need a bit more.
  79. It is simply a neat method of decoupling of dependencies - simply taking out explicit object creation from users code.
    Well, it reduces compile-time dependencies. Of course, runtime-dependencies still exist. They are just invisible in the Java code - which may have undesirable consequences.
  80. It is simply a neat method of decoupling of dependencies - simply taking out explicit object creation from users code.


    Well, it reduces compile-time dependencies. Of course, runtime-dependencies still exist. They are just invisible in the Java code - which may have undesirable consequences.
    This is true only if you use scripted, XML-based or other external descriptions of the dependencies. My point about IoC not necessarily being late-bound is that you can set up IoC entirely within statically compiled code. If you look at the examples of an IoC implementation like PicoContainer, there is a point of loss of type safety, due to casting as instances are retrieved from the container. However, it would in principle be possible to use Generics to remove even this. IoC and late-binding are largely orthogonal concepts. IoC need only involve a separation between the description of dependencies and the use in terms of code, whereas late binding usually involves a separation in time. However, the fact that in most implemenations both IoC and late binding are used together, introducing the run-time depencies you mention, seems to have confused things, so many consider them inseparable.
  81. Standard use of PicoContainer does not use either scripting or configuration files.

    As the documentation says:

    "The components are assembled in the container using a simple Java API that is similar to an intelligent hash map utilizing the type of its values."

    And as I said, Spring can be used entirely from pure Java code with no dynamic nature at all.

    To imply that IoC necessarily involves or implies late binding is just plain wrong, and a misunderstanding of what IoC is.


    I hesitate to dive into this maelstrom but here goes:

    My background: I was (might still be) a committer on NanoContainer. I developed the first cut of NanoContainer's AOP mechanism, and a scripted NanoAOP configuration mechanism via Groovy. I don't know if anything every came of that; I switched to using Spring when it became clear that is was becoming the dominant IoC framework and had developed a high quality implementation and good documentation. I also develop in Ruby and Rails.

    Here's why you don't really need IoC in languages like Ruby:

    IoC basically solves the 'new' problem. In languages like Java new is a built in operator that you can't override. It's not polymorphic. Take this code:


    date = new Date();


    That line ties my code to the concrete class java.util.Date, and to the implementation of the Date default constructor. I can't change that without changing my code. That code is hard to test. If only I could change the behavior of 'new'! In Java you can't.

    IoC works around that problem (that 'new' is not polymorphic) by flip-flopping the dependency and injecting in the concrete instance, as we all know. There are costs though: you have to anticipate the need for this flexibility up front (by not using the 'new' operator), more indirection which can make the code harder to follow, and more configuration files. Still it's a brilliant workaround for a language limitation.

    In Ruby (and other languages) however new is a polymorphic method of class Class, and classes are first class objects. So in Ruby you write this:


    date = Date.new


    Contrary to appearances that code does not tie me to a particular class or constructor. If I need to mock out the current date for unit testing I can do so either by overriding the factory method Date.new in my test, or more commonly by assigning the constant 'Date' to a new mock date class. The point is that in Ruby you don't need IoC to change the behavior of new. It's not really a static vs. dynamic thing but more an issue of how deep OO goes in the language.

    Of course this sort of thing scares the bejeezus out of died in the wool Java programmers. But programming to an interface not a concrete implementation shouldn't be scary. You're sending messages to encapsulated objects, not depending or caring about how or even when they're implemented. If you can deal with the fact that Spring can dynamically swap out implementations then Ruby shouldn't scare you that much. Once you start doing IoC you've lost much of the benefit of static typing anyway. If you want to verify the correctness of your code (and you should!), write tests.

    (I do realize that Spring is much more than just an IoC framework. It bundles together a whole slew of technologies into one coherent whole, like Rails. That's valuable with or without IoC. )
    Wow, great post Stephen, thanks for the clear explanation. Regarding the way Ruby solves the 'new' problem, don't you think the same is achievable in java via AOP? Is there an inherent limitation in java that prevents it from achieving the same even with AOP? I'm not really well versed in Ruby and would appreciate any notes on how it solves this problem in an elegant manner.
  82. AOP in Ruby[ Go to top ]

    I'm not really well versed in Ruby and would appreciate any notes on how it solves this problem in an elegant manner.
    AOP is easy in ruby, due to the open nature of its classes. here is a good link: http://wiki.rubygarden.org/Ruby/page/show/AspectOrientedRuby
  83. Standard use of PicoContainer does not use either scripting or configuration files.

    As the documentation says:

    "The components are assembled in the container using a simple Java API that is similar to an intelligent hash map utilizing the type of its values."

    And as I said, Spring can be used entirely from pure Java code with no dynamic nature at all.

    To imply that IoC necessarily involves or implies late binding is just plain wrong, and a misunderstanding of what IoC is.


    I hesitate to dive into this maelstrom but here goes:

    My background: I was (might still be) a committer on NanoContainer. I developed the first cut of NanoContainer's AOP mechanism, and a scripted NanoAOP configuration mechanism via Groovy. I don't know if anything every came of that; I switched to using Spring when it became clear that is was becoming the dominant IoC framework and had developed a high quality implementation and good documentation. I also develop in Ruby and Rails.

    Here's why you don't really need IoC in languages like Ruby:

    IoC basically solves the 'new' problem. In languages like Java new is a built in operator that you can't override. It's not polymorphic. Take this code:


    date = new Date();


    That line ties my code to the concrete class java.util.Date, and to the implementation of the Date default constructor. I can't change that without changing my code. That code is hard to test. If only I could change the behavior of 'new'! In Java you can't.

    IoC works around that problem (that 'new' is not polymorphic) by flip-flopping the dependency and injecting in the concrete instance, as we all know. There are costs though: you have to anticipate the need for this flexibility up front (by not using the 'new' operator), more indirection which can make the code harder to follow, and more configuration files. Still it's a brilliant workaround for a language limitation.

    In Ruby (and other languages) however new is a polymorphic method of class Class, and classes are first class objects. So in Ruby you write this:


    date = Date.new


    Contrary to appearances that code does not tie me to a particular class or constructor. If I need to mock out the current date for unit testing I can do so either by overriding the factory method Date.new in my test, or more commonly by assigning the constant 'Date' to a new mock date class. The point is that in Ruby you don't need IoC to change the behavior of new. It's not really a static vs. dynamic thing but more an issue of how deep OO goes in the language.

    Of course this sort of thing scares the bejeezus out of died in the wool Java programmers. But programming to an interface not a concrete implementation shouldn't be scary. You're sending messages to encapsulated objects, not depending or caring about how or even when they're implemented. If you can deal with the fact that Spring can dynamically swap out implementations then Ruby shouldn't scare you that much. Once you start doing IoC you've lost much of the benefit of static typing anyway. If you want to verify the correctness of your code (and you should!), write tests.

    (I do realize that Spring is much more than just an IoC framework. It bundles together a whole slew of technologies into one coherent whole, like Rails. That's valuable with or without IoC. )
    First, great post! Very well written. But there one part I disagree with you :
    If you can deal with the fact that Spring can dynamically swap out implementations then Ruby shouldn't scare you that much. Once you start doing IoC you've lost much of the benefit of static typing anyway.)
    This imply that you use IoC everywhere in your application something which is rarely true. Usually you use IoC to inject infrastructure services and connect layers together. I have rarelly seen domain objet getting injected (especially when you use a ORM framework). So Spring does allow you to keep the benefit of static typing in your domain model while giving you the benefit of dynamic typing to inject infrastructure services and connect the other layers of the applications together. As I pointed out earlier, I really think that not having the IoC or the Meta Class facilities part of the language is the key here, you can use it whereever you need it but switch back to the joy of static typing as you want (for instance when you express your domain model). Of course, this is only my opinion :)
  84. First, great post! Very well written. But there one part I disagree with you :


    If you can deal with the fact that Spring can dynamically swap out implementations then Ruby shouldn't scare you that much. Once you start doing IoC you've lost much of the benefit of static typing anyway.)


    This imply that you use IoC everywhere in your application something which is rarely true. Usually you use IoC to inject infrastructure services and connect layers together. I have rarelly seen domain objet getting injected (especially when you use a ORM framework). So Spring does allow you to keep the benefit of static typing in your domain model while giving you the benefit of dynamic typing to inject infrastructure services and connect the other layers of the applications together. As I pointed out earlier, I really think that not having the IoC or the Meta Class facilities part of the language is the key here, you can use it whereever you need it but switch back to the joy of static typing as you want (for instance when you express your domain model). Of course, this is only my opinion :)
    Hi Alexandre, What are the benefits of static typng within the domain model you speak of? I've produced domain models with both static and dynamic languages and I find both equally as applicable. Infact with a dynamic language like Ruby, you are more able to taylor your abstractions to your domain, leading to domain specific languages like ActiveRecord in Rails and the template helpers. Please explain, perhaps I'm misunderstanding you. Paul.
  85. First, great post! Very well written. But there one part I disagree with you :


    If you can deal with the fact that Spring can dynamically swap out implementations then Ruby shouldn't scare you that much. Once you start doing IoC you've lost much of the benefit of static typing anyway.)


    This imply that you use IoC everywhere in your application something which is rarely true. Usually you use IoC to inject infrastructure services and connect layers together. I have rarelly seen domain objet getting injected (especially when you use a ORM framework). So Spring does allow you to keep the benefit of static typing in your domain model while giving you the benefit of dynamic typing to inject infrastructure services and connect the other layers of the applications together. As I pointed out earlier, I really think that not having the IoC or the Meta Class facilities part of the language is the key here, you can use it whereever you need it but switch back to the joy of static typing as you want (for instance when you express your domain model). Of course, this is only my opinion :)


    Hi Alexandre,

    What are the benefits of static typng within the domain model you speak of? I've produced domain models with both static and dynamic languages and I find both equally as applicable. Infact with a dynamic language like Ruby, you are more able to taylor your abstractions to your domain, leading to domain specific languages like ActiveRecord in Rails and the template helpers.

    Please explain, perhaps I'm misunderstanding you.

    Paul.
    Hi Paul, First I want to correct what I wrote. When I was using the term dynamic language, I was actually referring to a language that has metaclass facilities but since the two are often linked, I didn't make the distinction. Well, I'll try to explain what I was meaning. As you might suspect english isn't my native language but I'll try to be as clear as possible. The ability to overrride the new operator or class method is very nice and elegant way to get IoC and/or AOP features out of the box. But I think it's somehow too powerful especially when it is used in your domain model. When I use the new operator in Java, I know I am going to get the object I instantiate but in SmallTalk (or Ruby), I have to check if the new class method isn't overrided. I never know what I am going to get unless I check this method. In Java, if I want to achieve the same, I have to ressort to use a static factory method or IoC (and you rarely use IoC in your domain model to inject domain objects), which is a lot more explicit. In fact, if we only consider the language, injection is the norm (or can be) in SmallTalk while in Java it is the exception (you can't use the new operator and therefore the injection becomes really explicit). To me the real power of object oriented programming is the clarity it gives. A new developer can get up to speed quite quickly if you have divised your program responsabilities in a elegant way. In Java, the new operator makes it clear what object you are going to get while in Ruby not only the developer has to understand the domain model but also the overlaying class model. Depending of your discipline and your programming style, it can't be quite hard to get familiar with someone else's code­. Of course, if you work alone it isn't a problem but who does? You have to think in term of two different layers (objects and classes) instead of one as in Java. My reasonning is I don't need all this complexity in the domain model except to inject some infrastructure services and to decorate my objects (transactions, security, auditing, ...) and therefore I don't want this capability to be implicit to the language. I want them to be the exception and to come from an external source (an external component), in order to make it easy to spot where those capabilities are used as it is the case when using a framework à la Spring. To me AOP and IoC while less powerful concepts are clearer and less abusable. Well I think that pretty much cover it. This isn't easy to explain. Also please note that my experience in SmallTalk is quite limited so I could be totally wrong.
  86. Hi Alexandre, Thanks for trying to explain. The feeling that comes across is a need for clarity, or perhaps certainty at development time. Where I can agree with you is that auto-completion for method names on objects in an IDE like Eclipse is a great tool, and although dynamic IDEs are getting better at this, they are still no where near close to providing the type of info literally at your finger tips that you can get with a Java IDE. The other point I like to say about clarity, is that in an OO language this should come from the messages. In Smalltalk they use keyword messages as a way of improving clarity. So for example you get messages like "do: x with: y". The idea being that they read more like English. So the messages define what an object can do, the methods tell you how it does it. As a client of an object all you should care about is the what. This is the crux of all of what I've been saying, and interestlingly where Spring steps in to help Java out. The problem with a dynamic language though is what happens when the messages aren't clear and self describing? Then I agree with you, tracking down the implementation is a lot more difficult then with a static language. The point though is that if the messages are well named, and are well designed then this should not be needed. The code should speak for itself. I would suggest that you read "Smalltalk Best Practice Patterns" by Kent Beck. It is full of idioms, patterns and techniques that bring clarity to Smalltalk code and many of the ideas are applicable to Java aswell. Infact it was here where I saw how Smalltalk does IoC in one line of code. The last point I want to make is to do with certainty. Static languages tend to promote the illusion that you can tie down what your code at development time. The simple truth is that you can't. Forgetting generics for a second, if you take a look at the vast majority of objects available in a Java program at runtime, they will be stored untyped in collections. So what really matters, is how your program looks at runtime, not how it looks statically in your IDE. So thinking live runtime objects leads to better programs then thinking static code on a page. If you look at the structure of a well written Smalltalk programm you will notice that the methods are very short (2 to 3 lines), and the messages do all the work. So it is the dynamic nature of the program through messaging that defines its behaviour, and less reliance is made on the code statically available to you in a single method. I think there is an issue with skill here also. Static languages in a way can be more forgiving, but then again you could argue that they allow you to build redundant, poorly designed, procedural code more easily. In my exprience, as you become more competent, you tend to notice that many of the things that first appear attractive (e.g. large methods, procedural programming etc), become traps, that can be harder to avoid in a static language. Having said this a competent programmer should be able to write good OO code with either a static or dynamic language. With a dynamic language though, the code tends to be more Object Orientated, for the reasons I've stated, which for me is a significant benefit. Paul.
  87. Hi All,

    I like Spring, but IMO it largely solves a problem of our own making. My view is that Spring took of because people wanted a loosely coupled late-bound component architecture without the overhead of an heavy-weight aplication server.

    Spring delivers this for Java programmers and does it well IMO. But why did we have heavy-weight containers in the first place? Why is late-binding of Java objects such a problem?

    It all stems back to C++, and it spawned component models: COM and CORBA. The lack of a dynamic message send in C++ led to the need for complex runtimes inorder to bind together objects after compile time. Along with the virtual function call, Java inherited this legacy from C++ and largely suffers the same problem, hence EJB's were mostly a Java re-implementation of CORBA.

    There are C based OO languages that avoided these pitfalls, for example Objective-C. Objective-C retained the OO messaging semantics of Smalltalk, at the cost of a little indirection at runtime. As a consequnce it lead to the extremely successful component model used in NextStep and now present in the Mac OS X user interface as Cocoa.

    Loose coupling and late-binding is what Spring is all about IMO. These architectual qualities are more easily delivered using a dynamic OO language with late-bound, polymorphic message sends (instead of early-bound virtual function calls).

    This is why I see Spring as a stepping stone along the path to fully dynamic architectures, and I see Rails and Ruby picking up where Spring and Java hit their inherent limits.

    Paul.
    I agree with you on the first part but not on your conclusion. To me Spring offers the best of both world, ie expressing your domain model using a static typed language while allowing you to get transparently infrastructure services (thank to DI and AOP) as you would be able natively if you were using a dynamic language à la Ruby. I think this hybrid nature is why Spring is so successful, it just brings a lot of the advantages found in dynamic typed languages to a static typed language without the shortcomings.
  88. Hi All,

    I like Spring, but IMO it largely solves a problem of our own making. My view is that Spring took of because people wanted a loosely coupled late-bound component architecture without the overhead of an heavy-weight aplication server.

    Spring delivers this for Java programmers and does it well IMO. But why did we have heavy-weight containers in the first place? Why is late-binding of Java objects such a problem?

    It all stems back to C++, and it spawned component models: COM and CORBA. The lack of a dynamic message send in C++ led to the need for complex runtimes inorder to bind together objects after compile time. Along with the virtual function call, Java inherited this legacy from C++ and largely suffers the same problem, hence EJB's were mostly a Java re-implementation of CORBA.

    There are C based OO languages that avoided these pitfalls, for example Objective-C. Objective-C retained the OO messaging semantics of Smalltalk, at the cost of a little indirection at runtime. As a consequnce it lead to the extremely successful component model used in NextStep and now present in the Mac OS X user interface as Cocoa.

    Loose coupling and late-binding is what Spring is all about IMO. These architectual qualities are more easily delivered using a dynamic OO language with late-bound, polymorphic message sends (instead of early-bound virtual function calls).

    This is why I see Spring as a stepping stone along the path to fully dynamic architectures, and I see Rails and Ruby picking up where Spring and Java hit their inherent limits.

    Paul.


    I agree with you on the first part but not on your conclusion. To me Spring offers the best of both world, ie expressing your domain model using a static typed language while allowing you to get transparently infrastructure services (thank to DI and AOP) as you would be able natively if you were using a dynamic language à la Ruby. I think this hybrid nature is why Spring is so successful, it just brings a lot of the advantages found in dynamic typed languages to a static typed language without the shortcomings.
    Hi Alexandre, We are allowed to disagree on conclusions :^) I am just glad that you acknowledge the underlying problem Spring attempts to solve. As for a hybrid approach, I believe that there is mileage in it when appropriate. In fact Ruby and Rails is an hybrid, as the low level I/O is written mostly in C. Objective-C also allows for an hybrd approach. You can inline C and C++ code with Objective-C. I just wanted to focus the debate on what I feel are the real issues, hence the title. Paul.
  89. Slight correction[ Go to top ]

    Just noticed that I failed to correct an error in the original post...
    Voca has handled 80M transactions since.
    Voca has handled up to 80 million transactions each day since deploying a Spring-based application, amounting to billions of transactions in total. Rgds Rod
  90. Re: Slight correction[ Go to top ]

    Hi Rod, Not knocking the Spring framework itself but I think this last posting smells too much of "quality transference". State a large number (80 million) and then juxtapose a commercial brand name (Spring). Can you please be a little more factual in explaining how Spring is an integral part of the scalability and performance of such a system? I always thought that Spring's core offering was the improved management of an application initial component construction and association (dependency) - once the dependency injection has taken place (whether these are placeholders or not) the application had very little Spring interaction during the course of the execution. I am aware of the wrapper like interfaces around standard API's and the lightweight single/local resource transaction management but what other capabilities of the framework have a bearing on the 80 million transactions. I would be very interested in knowing the work horses of the application such as the distributed component technology (RPC), local/distributed transaction managers, local/remote resource managers (JMS/JDBC drivers and server backends),..... I have always assumed Spring was a framework designed solely to improve the quality of designs that relied on other integrated technologies and platforms to achieve high performance and scalability. For a validation of the framework I would think the focus should be on other metrics that equate to the underlying complexity of the problem managed effectively by Spring. I hope that you understand that this is not an attack on the framework itself but on this particular slip in messaging that gives others a reason to knock the Spring brand and the usefulness of the framework and its concepts. You mention plans to expand the Spring branding to other projects but do you have any plans to to become a standard? At version 2.0 the stability and maturity in the concepts should be there to take this option much more seriously. It would be great to see the Spring team to take a leaf out of Gavin's book and push to decouple the project from the Interface21 implementation. Gavin & Co. managed this successfully with EJB3 and he is now hoping to repeat this success again with WebBeans (Seam). Such a move would satisfy those risk management conscious enterprise architects who prefer to interface with open source and commercial products via industry standard interfaces & deployment descriptors. Regards, William Louth JXInsight Product Architect JInspired "Java EE tuning, testing, tracing, and monitoring with JXInsight" http://www.jinspired.com
  91. Re: Slight correction[ Go to top ]

    William, I work for VOCA and was one of the lead architects for the programme Rod mentioned. Ability to handle more than 100m transactions is only one aspect of the system. The programme itself was a technology refresh for an existing infrastructure that has been handling the UK payments infrastructure for more than thirty years. The programme consisted of a myriad of sub-systems, which all involved Spring in one way or the other. Spring, was instrumental in enforcing best practices like loose coupling, substitutability, improved testability, modularisation, enhanced developer productivity, better exception management etc. Spring's JDBC and JTA abstractions were also handy in writing the persistence layer and transaction management abstractions. However, I would also like to mention that Hibernate, Weblogic, Oracle RAC and Solaris were also key in achieving the scalable architecture we have at VOCA. We were able to deliver an extremely complex programme on time, on budget meeting stringent quality and performance requirements. I would say, this would have been highly unlikely without Spring. Meeraj Kunnumpurath Enterprise Java Architect VOCA http://www.voca.com
  92. Re: Slight correction[ Go to top ]

    Rod, In our Spring world: Last year we delivered a project for a major financial institution handling more than 3 million transactions per day. -Arshad
  93. I do not like to frequent TheServerSide forum as I find the audience too opinionated and abrasive on almost any subject. However, as one of the earliest adopters of the Spring framework (before it was even Spring but set of interface21 packages from Rod's first book) I have to say few honest words about it: - I do not doubt Rod's figures and words. Spring at the time it came out was the sane alternative to over-engineered J2EE spec madness. I find broad adoption of the framework possible, natural and justifed. In my case, that is not for Spring all my apps would probably be in .NET now. - Spring's huge practical value is in its good performance. I am not at freedom to speak of the exact nature of my Spring applications, but I can say that they are all heavily taxed, extremly mission critical and they all exhibit excellent performance - mostly due to Springs "slim" footprint and smart bean instance management. - Spring's XML based configurations are my single largest complaint about it. There is simply way too much XML wiring going on. I know it is getting better with 2.0 (which I have not applied yet), and I hope that Spring team will continue to push reduction of XML as much as possible. - Spring's core team, as compared to other major open source framework circles I had to deal with, is by far the friendliest and most business savvy crowd I had to deal with. Spring forum was a (at least last I checked at) mature and helpful place where egos, RTFMs, and opinionated attitudes were always in check. I am a professional, I like to be treated that way and in my interactions with people from Spring team I feel that I am dealing with other mature professionals, not some egotistic open source super stars. I have significant influence in terms of hiring consultants. If serious and expertly help needed they will be the first on my list. - Depending on where Java EE 6, 7,.. go Spring may loose its role and importance. I often say that Spring is probably a transitional framework (unless if Java EE dies off). I call it transitional because of its role in taking a J2EE mess and making it usable. Ideas it presented in that process may eventually spur some "offical" innovations in the Java EE spec itself that in turn may result in a far better Java EE and therefore killing the need for Spring after all. I think this may happen. That is the cycle that we all live in. Regardless, I do wish Rod and his Interface 21 crew lots of luck in their business. I think they have done a great service to Java EE community, and they have given us a quality product that has made the practical difference in our architectures. Respectfully, Edmon Begoli Senior Architect
  94. Nice post. +1 I think Spring's contribution has been it's ability to offer an alternative to the dogmatic and increasingly complicated path of J2EE components and container vendors. Spring was the right technology at the right time to push as new orthogonal paradigm around development. Spring was different in that it leveraged IoC and one-up'd Pico while concurrently leveraging other non-J2EE technologies, specifically Hibernate. The claims that Spring performs so well (Vaca) seem to be miss that true enabler that Spring is all about development (speed and maintainability). I classify it as an enabler like Struts was. Struts opened the doors to better MVC and faster more organized development. Nobody complains about how Struts performs other than it early use of reflection. The future of Spring is bright. Its features, conventions, and competitive advantage will be assimilated as is happening with Ruby on Rails now. It continues to build out comparable features that EJB containers and thread models provide - OSGi for deployment and Message Listeners for threads. Alas Spring will become the next Struts, ubiquitous but long in the tooth. For now its still on its ascendancy.
  95. Spring in 2007- rich web?[ Go to top ]

    Talking about any web applications platform or framework in, one cannot miss the new web applications. While Web2.0 may be hyped way beyond what it merits, I believe there sure is sufficient substance to warrant support from app platforms. To that extent will be interesting to see what Spring and Struts, will hold forth in 2007. Lately, Jay Pullur, Founder of Pramati has started sharing his thoughts on changes in the web applications platforms. Some interesting thoughts on his blog- http://pullur.wordpress.com. IN all, will be inetersting to see what the application platforms and the frameworks like Spring will offer in 2007.
  96. just see it,but it's very exciting! :)
  97. Productivity Award[ Go to top ]

    I notice Rod forgot to mention the Productivity Award Spring Framework won at the 16th Jolt Product Excellence Awards in March. Now the list is complete.
  98. Re: Productivity Award[ Go to top ]

    David
    I notice Rod forgot to mention the Productivity Award Spring Framework won at the 16th Jolt Product Excellence Awards in March.

    Now the list is complete.
    Apologies for this omission - that was also a milestone for Spring.. I knew I was going to forget a lot of important stuff... It was a busy year. Thanks for the correction! Rgds Rod
  99. Re: Spring in 2006: A year in review[ Go to top ]

    Above all ,Spring and it's teammate have already done a lot and lot for the open source JavaEE ,many people and company are benefit from them. So, first, we should say to them "Thanks very much!" Secondly, we all know that -- The "Technologies" has NO "good" and "not good", ONLY has "well done to be used" and "NOT well done to be used" . I mean that : Is the developers who decide the applications or products good or not ,not "Spring" itself! So ,if you think Spring is good for your product ,then ,you can use it ,and MUST use well,this is the KEY; if not ,you can choose others, and whatever you choose, you must make this in your mind -- using it well. The Key is people ,not technology itself ,isn't it?! Neo Shan