Spring 2.0 goes final

Home

News: Spring 2.0 goes final

  1. Spring 2.0 goes final (163 messages)

    The Spring Framework project has released version 2.0 final. This release is based around two themes: simplicity and power. The Spring Framework has always reflected the belief that it is possible to provide a simple, productive model that scales to handle the most complex of applications. In version 2.0 there are improvements in both respects, as many tasks become easier, while the scope of the framework broadens and significant new capabilities are added. Spring 2.0 is almost entirely backward compatible. Most users can expect updating to the new version to be as straightforward as replacing the 1.2.8 JAR files with those included with Spring 2.0. Spring 2.0 has undergone extensive testing and community feedback across 9 milestones and release candidates over 9 months, to ensure backward compatibility as well as the high quality standard the Spring Framework is known for. "Spring 2.0 introduces many refinements and extensions in a natural and seamless fashion, preserving all core APIs and configuration facilities," said Juergen Hoeller, Spring Framework lead developer and VP and Distinguished Engineer at Interface21. "The new schema-based XML configuration model is a major enabler for convenient and extensible configuration, which we were able to introduce without major impact on the Spring core." "We believe that version 2.0 going GA is a major advance for Spring Framework users and enterprise Java overall," said Rod Johnson, founder of the Spring Framework and CEO of Interface21. "Users I speak to are excited about the new features and many have been waiting eagerly to put them into production. The Spring Framework pioneered the concept of developing sophisticated applications from plain Java Objects (POJOs), and continues to set the benchmark for POJO development. The fact that Spring 2.0 is backward compatible confirms the power of what we call a 'non-invasive' POJO-based programming model, and the quality and flexibility of the Spring Framework's architecture. Users who have invested in applications built on Spring can rely on us for a stable upgrade path." The many new features and enhancements in Spring 2.0 include:
    • Numerous enhancements in the core Inversion of Control container, including the addition of custom scopes for Spring beans (with HTTP session and request scopes out of the box), and further extension points for use by the growing number of third party frameworks building on Spring, including the Pitchfork project used in the next release of WebLogic Server.
    • Extensible XML configuration, built around XML schema, with the ability to create namespaces defining custom elements that can be reused as building blocks. This feature enables many common tasks to be simplified through custom tags shipped with Spring itself, organized into namespaces around areas such as AOP, Java EE integration and transaction management. It also provides a major benefit for the many third party products that use Spring internally, such as Mule, and is important to large enterprise users who want to define configuration extensions for use across very large projects.
    • Major improvements in Spring's support for Aspect Oriented Programming (AOP). Spring 2.0 evolves Spring's AOP framework to take advantage of the powerful AspectJ pointcut expression language, which provides a sophisticated way of identifying points in the execution of an application to which aspect behavior should apply. Spring 2.0 allows Spring users to leverage the powerful and elegant AspectJ programming model with the Spring runtime, preserving the zero cost of adoption of Spring AOP. The AspectJ programming model delivers many advantages beyond interception-based programming models, such as type-safe matching, avoiding the potential for brittle assumptions regarding method arguments and return types. Through enabling key elements of the AspectJ programming model "natively" in the Spring Framework, Spring users gain the unique advantage of a single programming model for all AOP requirements, being able to use the same concepts and constructs if they choose to use AspectJ in addition to Spring. Spring 2.0 provides a complete roadmap for AOP usage, meeting the needs of all users, whether or not they simply want to use Spring’s out of the box declarative services such as transaction management, want to use Spring AOP for custom aspects or want to use AspectJ for the most demanding AOP scenarios.
    • Improved functionality for JMS messaging, including a sophisticated capability for asynchronous message consumption both within and outside a J2EE environment. The latter supports local JMS transactions as well as XA transactions, and can be integrated with any kind of thread pool through Spring 2.0's new TaskExecutor abstraction.
    • Numerous features designed to take advantage of language improvements in Java 5 for customers who have already updated their environments.
    • The extension of the Spring component model to support dynamic languages running on the JVM, including JRuby, Groovy and BeanShell. As of Spring 2.0, the Spring component model is cross language, and any Spring bean can be coded in a choice of languages. Regardless of language, all Spring components enjoy the full range of Spring services, such as Dependency Injection and enterprise services such as declarative transaction management and JMX export.
    • Improvements in Spring MVC web framework, including additional defaulting and a new JSP tag library that simplifies form authoring.
    • Addition of a Portlet MVC framework that provides similar benefits to Spring MVC for developing Portlet-based web applications. This has been one of the most common requests from the Spring community.
    • First-class integration with the Java Persistence API (JPA) standard for object-relational mapping, with Spring able to provide both the Java SE and Java EE contracts for hosting a JPA persistence provider, and processing JPA annotations such as @PersistenceContext. This extends Spring’s comprehensive architectural solution to data access to span an important new technology.
    For more information and downloads, see the offical launch page. Spring 2.0 can be downloaded here. The Spring documentation has been extensively updated for Spring 2.0, and contains a summary of how the new features in Spring 2.0 affect developers. Like previous versions of the Spring Framework, Spring 2.0 runs on all web containers and application servers, as well as in standalone environments. It continues to run on Java 1.3 and above, although some new features are available only on Java 5.

    Threaded Messages (163)

  2. ...and Spring web site crashes[ Go to top ]

    Looks like any hype generated by the official release countdown on the Spring web site had a negative side-effect: the web site is now down. I guess some people can't wait to get their hands on the official release, myself included ;-)
  3. Looks like any hype generated by the official release countdown on the Spring web site had a negative side-effect: the web site is now down. I guess some people can't wait to get their hands on the official release, myself included ;-)
    Maybe if they'd have used Java on the web site... *ducks*
  4. Re: ...and Spring web site crashes[ Go to top ]

    I can image why Spring web site is down. It also prompt me whether I should use Spring in high traffic site. I like Spring, but I like Spring-OSGI better. I will wait and move on later.
  5. Re: ...and Spring web site crashes[ Go to top ]

    I can image why Spring web site is down. It also prompt me whether I should use Spring in high traffic site. I like Spring, but I like Spring-OSGI better. I will wait and move on later.
    In all fairness, the Spring website is on PHP, if I recall correctly. So maybe .this is a validation of Java, more than a failure of Spring. :)
  6. Re: ...and Spring web site crashes[ Go to top ]

    Looks to me more like a database issue than a language issue.
  7. Re: ...and Spring web site crashes[ Go to top ]

    I can image why Spring web site is down. It also prompt me whether I should use Spring in high traffic site.
    As Joe pointed out, the Spring web sites are not Spring-based or even Java based, but PHP based. The outages indicate that Spring is extremely popular, not that it doesn't scale. Spring itself scales :-) Virtually all UK interbank payments (upwards of 70m per day, including virtually all salary and utility payments) are processed by a Spring-based application run by Voca. It significantly exceeds the performance of the mainframe it replaced, and dramatically exceeds the performance of previous attempts to migrate the project to enterprise Java. And amongst high-volume websites, 34m French taxpayers are served by a Spring-based solution that has produced exceptionally good performance and reliability. Yes, the upcoming integration between Spring and OSGi is very promising. This is a major priority, post Spring 2.0. Rgds Rod
  8. BTW, my comment about the site being down was not a slight at Spring, just an observation :-) Congrats to the Spring team on some great work!
  9. Re: ...and Spring web site crashes[ Go to top ]

    Congratulations! We've been using Spring 2.0 milestones for some time now in some of one core applications. I'll sleep a little better once we've switched to the full release version.
    As Joe pointed out, the Spring web sites are not Spring-based or even Java based, but PHP based.
    That leads to an obvious question: why aren't you drinking your own Kool Aid?
  10. Congratulations! We've been using Spring 2.0 milestones for some time now in some of one core applications. I'll sleep a little better once we've switched to the full release version.

    As Joe pointed out, the Spring web sites are not Spring-based or even Java based, but PHP based.

    That leads to an obvious question: why aren't you drinking your own Kool Aid?
    Time, I answered this above. Basically what it comes down to is at the time the software for the main .org web site and forums was chosen, there was simply nothing Spring-based (or even Java-based) that would have fit the bill, given the combination of features we needed, time we had available, hardware we had to run it on, and funds available to spend on the sites. The forum software was originally picked as phpBB back in summer 2004, and last year, when we wanted something better, the only easy upgrade path to a better product without losing old posts (not a possibility) was to vBulletin. The CMS for the web site was picked in Spring 2005, and there was simply nothing Java or Spring-based at the time that would have fit the bill. Drupal is pretty feature rich, and got us going quickly. We have always been extremely resource constrained, so it would not have made sense to pick anything that would have required a large investment of time (like building something ourselves). There are simply better things we can do with our time, like working on Spring itself. These days, the situation is pretty much different. There are a number of Java based forum and CMS products out there that are pretty good, and some of them are even Spring-based. So we would probably not make the same decision today... Regards, Colin -- Colin Sampaleanu Principal, Interface21 Spring Training, Consulting and Support - "From the Source" http://www.interface21.com
  11. Re: ...and Spring web site crashes[ Go to top ]

    Are you sure voca never dropped it? Perhaps you are referring to the pilot they did a while ago.
  12. Re: ...and Spring web site crashes[ Go to top ]

    Are you sure voca never dropped it? Perhaps you are referring to the pilot they did a while ago.
    Raymond, no Spring thread would be complete without you :-) Yes, I am 100% sure that Voca are using Spring in production in their core payment engine, which is critical to the UK economy. It seems you know nothing about Voca's technology choices, so I'm not quite sure what the point of your post is. Voca are so happy with their choice of Spring that Nick Masterson-Jones, Voca's Director of Information Technology, spoke during a keynote session at the recent SpringOne conference at SpringOne. The video of that keynote will be available soon. In the meantime, the slides from another SpringOne presentation on Voca's usage of Spring, by Jonathon Donovan, a Voca architect, are available on Voca's web site here. I would hope that it was obvious that I would not be naming such an organisation publically unless I had their permission to do so as a public reference, and unless my information was up-to-date. Btw, Voca have an extraordinary record of delivering high-quality solutions: their standards are very high. In over 30 years of handling nearly all interbank payments in the UK, they have never lost a payment. So they do not use software that isn't totally reliable. Rgds Rod
  13. Thanks Rod for pointing to the Voca stack. I was wondering how they used Spring. It appears it is Spring/Hibernate/WebLogic/Oracle/Sun that needs to be referenced as part of the complete solution. I pictured a public static void main() on a POJO being the heart of their system. http://www.voca.com/NR/rdonlyres/C7B9012F-766F-432D-8218-C3AA12CDBBA9/0/PaymentEngineCaseStudySpringone.pdf
  14. More than anything, Spring was instrumental in enabling us to deliver a large and complex programme on time, on budget and to stringent quality standards. We have been in production for the past four months, and only recently, we processed our newest peak day with more than 80.3 million transactions. To list a few Spring features that enabled us to build the system, 1. Ability to test our application in and out of an enterprise Java server increased developer productivity by 60-70 %. 2. Enhanced the testability of the applications and underlying components. 3. Spring JDBC abstraction framework provided an elegant mechanism for direct access to relational databases using SQL. 4. Usage of Spring promoted better practices in-terms of componentalization, interface-based interaction and substitutability. 5. ORM integration 6. Transaction management abstraction The other technologies mentioned in the stack have also been exteremely important for us in delivering a performant and scalable robust solution. We have been using Spring on other applications prior to this programme and we continue to use it as well. We are using Spring 2.0 quite extensively for JPA integration with Hibernate 3.0 entity manager and JPA annotations. Spring also works quite well for us with other OSS ESB products we have been using. Meeraj Kunnumpurath Enterprise Java Architect VOCA http://www.voca.com
  15. I think Meeraj makes the best points about why to use Spring - namely, the increased productivity during development and test, as well as the promotion of better design practices. It is always good to hear users report the performance, scalability, and reliability of apps based on Spring. Those reports emphasize that Spring won't hurt you in any of these areas. But for me, it's the ease and simplicity of building scalable/reliable/etc. apps on top of Spring that is the most compelling reason for continuing to use Spring.
  16. Voca & Spring[ Go to top ]

    More than anything, Spring was instrumental in enabling us to deliver a large and complex programme on time, on budget and to stringent quality standards.

    We have been in production for the past four months, and only recently, we processed our newest peak day with more than 80.3 million transactions.

    To list a few Spring features that enabled us to build the system,

    1. Ability to test our application in and out of an enterprise Java server increased developer productivity by 60-70 %.
    2. Enhanced the testability of the applications and underlying components.
    3. Spring JDBC abstraction framework provided an elegant mechanism for direct access to relational databases using SQL.
    4. Usage of Spring promoted better practices in-terms of componentalization, interface-based interaction and substitutability.
    5. ORM integration
    6. Transaction management abstraction

    The other technologies mentioned in the stack have also been exteremely important for us in delivering a performant and scalable robust solution. We have been using Spring on other applications prior to this programme and we continue to use it as well. We are using Spring 2.0 quite extensively for JPA integration with Hibernate 3.0 entity manager and JPA annotations. Spring also works quite well for us with other OSS ESB products we have been using.

    Meeraj Kunnumpurath
    Enterprise Java Architect
    VOCA http://www.voca.com
    Hi Meeraj, This is very interesting. Is there any kind of publicly available write-up on this? Might make useful reading. Kit
  17. Re: ...and Spring web site crashes[ Go to top ]

    The www and forum sites are not running on Java or Spring. The http://www.springframework.org site is running on Drupal 4.6, backed by MySQL 4.x, while on the same box, the forums at http://forum.springframework.org are running on vBulletin 3.6, backed by PostgreSQL. This is a pretty heavy duty box (Pentium 4 Xeon 2.8 or thereabouts, with SCSI raid hard drives and 2GB of memory. Drupal and vBulletin are pretty scalable, especially on this hardware, so while the sites going down is unfortunate, this is simply a testament to the huge amount of interest in Spring 2.0. The countdown has been out there for 4-5 days, and there are a number of articles linking to the release. As to the old question of why we used non-Java software to run the www and forum sites for Spring, this has been answered before. At the time the software was picked almost 2 years ago, we went through a pretty extensive review process of what was out there w/regards to options for a CMS and for forum software, and picked the best products for our needs based on the entire set of criteria, without worrying about the language behind the products. This was a pragmatic choice since our focus is on expending limited resources to put out the best Java framework out there, not exert some of that limited time towards something we could get off the shelf. Were the same choice to be made today, there would be a number of Java and Spring based solutions that would also fit the bill, and would probably be used instead. I want to add that the Spring Framework sites and the Interface21 sites (http://www.interface21.com) run in a datacenter managed by Contegix. Contegix have provided absolutely incredible managed hosting for us over the last couple of years, and I can not recommend them highly enough. This outage has nothing to do with them (again, it seems to be basic load limits at work, aka the "Slashdot" effect), but they are working on trying to tune things to get us going. -- Colin Sampaleanu Principal, Interface21 Spring Training, Consulting and Support - "From the Source" http://www.interface21.com
  18. I also have only great things to say about Contegix - we are in the process of moving to them as hosts, and the service and quality have been amazing. They know what they are doing. Anyway, it's funny to see people take it as a negative to the framework that the site took a hit - to me it's a huge sign of confidence that the community interest is greater than the infrastructure could take in that moment - victims of your own success, I hope you are laughing about it. Not to restart a CMS war, but I thought that interface21.com && springframework.com were plone (not drupal) based, unlike the .org site that took a brief sabbatical... ...and yes, I am a plone enthusiast, and wear it on my sleeve. -Andrew Kuklewicz, prx.org
  19. Re: ...and Spring web site crashes[ Go to top ]

    The downloads are also available directly from SourceForge. We are working to resolve the outages on the org site ASAP. Maybe we should have based our sites on a Spring-based solution.... But we have finite bandwidth and figured that people would rather we worked on Spring and the documentation :-) Rod Johnson, Spring from the Source
  20. Maybe if they'd have used Java on the web site... *ducks*
    Maybe if TSSJS 2007 website didnt use ASP on its site ... Hello pot, kettle here.
  21. Maybe if they'd have used Java on the web site... *ducks*

    Maybe if TSSJS 2007 website didnt use ASP on its site ...

    Hello pot, kettle here.
    Agreed! I'd prefer to use Java all over, but realise that we're an enterprise, too, with various skills all over. I don't blame Spring for using Drupal, really. It's just fun. :)
  22. Hey we're up![ Go to top ]

    We are back up! (I hope it holds ;-)) The official announcement is at: http://www.springframework.org/go-2.0 Yeah!!! Congratulations to all in the Spring community on this important release! Keith
  23. Hey, I was just kidding[ Go to top ]

    You guys response too fast. congratulations to Rod and Interface 21 team. I have been using Spring for couple years, no compliant so far. OSGI model is definitely more promising than messy loosely xml base configuration.
  24. congratulations[ Go to top ]

    Congratulations Spring team! -all the way from ph
  25. Re: congratulations[ Go to top ]

    Congrats to the I21 team with another milestone in lightweight Enterprise Java Development :) -Stephan
  26. Download[ Go to top ]

    http://sourceforge.net/project/showfiles.php?group_id=73357
  27. Anyone know when central will be updated with 2.0 final?
  28. Ben Hale (http://opensource.atlassian.com/projects/spring/browse/SPR-1484#action_1999) has been testing Spring 2.0 POMs with the help of the community leading up to the release today. He will be coordinating with the Maven2 team to get the final 2.0 jars and POMs in the coming days (as soon as responsibly possible). Keith
  29. maven[ Go to top ]

    Who updates the maven sites http://www.ibiblio.org/maven2/org/springframework/spring/ etc...
  30. Finally![ Go to top ]

    The site works OK for me. Many thanks to Rod, Colin, and of course Juergen and others for enormous effort you've done. 2.0 is a long-awaited release, and there is a bit of irony that so important release of Spring is made in autumn :) Anyway, considering the quality of code in previous releases I believe that 2.0 will be a highly reliable basis for new applications right from the beginning. The only thing left for me is to convince our management to go for it. Well done!
  31. Autumn???[ Go to top ]

    It's only autumn in the northern hemisphere! ;-) Congrats on the Spring 2.0 release. We've been playing with a few of the new features for months now with the milestones and RCs, and really like it. John Hurst Wellington, New Zealand
  32. Spring WEB Flow Release[ Go to top ]

    When can we expect a SWF release to follow? Thanks Pat
  33. Re: Spring WEB Flow Release[ Go to top ]

    Hi Pat, Here is the current Spring Web Flow release plan: - We are updating our code to reflect the final bean definition parser API in Spring 2.0 final just released. - We expect to release SWF 1.0 RC4 Wednesday (tommorrow), at the latest Thursday. We are ready. - With 1.0 RC4 we will deliver a proposal to the community for taking it to 1.0 final next week, starting the SWF final countdown and leaving the week to catch any lingering issues. I'd expect to see SWF 1.0 final most likely Wed or Thu of next week. Keith
  34. InheritableThreadLocal memory leaks[ Go to top ]

    Spring 2.0 increased its use of InheritableThreadLocal, making it all too easy to leak huge object graphs. Such a far-fetching implementation detail should be configurable (Strategy pattern etc), especially since jdk7 will be shipping with at least one new ThreadLocal implementation. There's already a JIRA issue: this is caused both by the LocalContextHolder and the new AOP context stuff.
  35. Re: Spring 2.0 goes final[ Go to top ]

    Congrats to the Spring team. Not only have you created software that I enjoy using and excellent documentation, but you've spread the IoC/POJO Gospel which helps create less cringing when I look at other people's code :-)
  36. Re: Spring 2.0 goes final[ Go to top ]

    Congratulations to all the folks that worked so hard to get Spring 2.0 finished. A lot of new features were introduced in 2.0, including the JPA integration. I want to thank the Spring team for getting an integration done in such a short time period and being such a vocal supporter and proponent of JPA. Shipping the JPA Reference Implementation also allows this to work right out of the box. Nice! -Mike
  37. Re: Spring 2.0 goes final[ Go to top ]

    Congratulations to all the folks that worked so hard to get Spring 2.0 finished.
    Thanks Mike for the support, and thanks to you and others in the TopLink team for being so responsive and helpful regarding our JPA integration and helping to ensure that it delivers maximum value to users. Rgds Rod
  38. Re: Spring 2.0 goes final[ Go to top ]

    Congratulations Rod & team on the release. What's the adoption look like so far with 2.0? (I'm hoping we can focus mainly on 2.0.) Also, ditto on Contegix. We're very pleased with them. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  39. Re: Spring 2.0 goes final[ Go to top ]

    Congrats to Rod and team! We've been using Spring for years now to power Liferay and are loving the flexibility and ease it provides. Thanks for the hard work. -- Brian Chan Chief Executive Officer Liferay, LLC Enterprise. Open Source. For Life.
  40. Re: Spring 2.0 goes final[ Go to top ]

    Congrats to Rod and team!

    We've been using Spring for years now to power Liferay and are loving the flexibility and ease it provides. Thanks for the hard work.

    --
    Brian Chan
    Chief Executive Officer
    Liferay, LLC
    Enterprise. Open Source. For Life.
    ` We have been using Spring and Liferay for the last two years are really love the power it offers for building complex IT systems. Many thanks to Rod and to the whole team for their work. Bertrand Pinel Chief Technology Officer Ippon Technologies, France
  41. Re: Spring 2.0 goes final[ Go to top ]

    Congratulations Rod & team on the release. What's the adoption look like so far with 2.0? (I'm hoping we can focus mainly on 2.0.)

    Also, ditto on Contegix. We're very pleased with them.

    Peace,

    Cameron Purdy
    Tangosol Coherence: The Java Data Grid
    Definitely big congrats to the Spring team... The milestone releases of 2.0 have been very stable and we've been using them for... almost a year? Can that be right? Wow... I'd say focus on 2.0. With the addition of custom scopes, the XML config updates, etc. it's a must-have upgrade. Jason
  42. More congratulations[ Go to top ]

    Spring is really a very good framework. I pushed it on my last three projects, and everybody was really happy with it. Great thing it continues to evolve in the good direction (functionnalities without losing simplicity). Good job! Cyril Gambis
  43. Re: Spring 2.0 goes final[ Go to top ]

    At the risk of being repetitive, CONGRATULATIONS!! My company has been using Spring since 04' and we've been extremely happy with the results. We've made our customers and theirs happy with this excellent technology. I'm looking forward to using Spring 2.0 in the next generation of our framework. Moving to Spring, JSF, and Hibernate 3 will allow us to achieve a whole new level of functionality in our products. I feel very fortunate that I can derive so much pleasure(and income) from the technologies available to Java today. But what's next...:-)
  44. Reviews[ Go to top ]

    Is there any in depth review of Spring as a whole? I can count in the fingers of one hand the quantity of blogs criticizing Spring, why don't we see more of that? The documentation in the website sounds more like a sales pitch. Spring is the kind of thing that no one knows exactly what it is for sure, but everyone praises it just in case. If you reveal the code obfuscation created by DI people will talk about Spring AOP, if you criticize the "goto" behavior of AOP people will talk about tests, and so on, indefinitely. Why creating tons of XML is a good thing? Why taking things from Java code to XML is a good thing? Why creating such overhead is a good thing? I have a theory, Spring the #1 way of scaring people away from Java. They don't do OO, they do "Spring oriented programming" and people start thinking that in order for anything to be done in Java you need a "Spring-esque configuration file hell".
  45. Re: Reviews[ Go to top ]

    I think you don't know exactly what it is for sure and as a result are criticizing it pretty unjustly (and incoherently). I think if you took the time to understand what it is and what it does, you'd find it useful. Frankly, the idea of "Spring the #1 way of scaring people away from Java" is about as ironic a statement as could be imagined given Spring's origins and what it was intended to fix.
  46. Re: Reviews[ Go to top ]

    I think you don't know exactly what it is for sure and as a result are criticizing it pretty unjustly (and incoherently). I think if you took the time to understand what it is and what it does, you'd find it useful.
    Spring is uncommunicable. I am still to meet a single person that can summarize in words what Spring is for.
    Frankly, the idea of "Spring the #1 way of scaring people away from Java" is about as ironic a statement as could be imagined given Spring's origins and what it was intended to fix.
    Sad but true.
  47. Re: Reviews[ Go to top ]

    Spring is uncommunicable. I am still to meet a single person that can summarize in words what Spring is for.
    "Spring is for" the simplification of, and the insulation of programmers from the most error prone portions of, a boatload of common Java usage patterns. At least that is what it has been to me over the past few years.
  48. Re: Reviews[ Go to top ]

    "Spring is for" the simplification of, and the insulation of programmers from the most error prone portions of, a boatload of common Java usage patterns.
    So, some kind of IDE Wizard could replace Spring?
  49. Re: Reviews[ Go to top ]

    "Spring is for" the simplification of, and the insulation of programmers from the most error prone portions of, a boatload of common Java usage patterns.
    So, some kind of IDE Wizard could replace Spring?
    I think that you are being deliberately obtuse. I was trying to sum it up, but I don't think that you are willing to listen. So...have a nice day. :-)
  50. Re: Reviews[ Go to top ]

    I was lucky enough to attend a days worth of presentations on Spring put on by Chariot Solutions.(http://www.chariotsolutions.com/javalab/presentations.jsp). I attended two great Matt Raible presentations. Picture Emeril running IntelliJ Idea. I have been using Spring now for a couple years and mostly appreciate the design aspects that are sometimes all too subtle such as object visibility, composition over inheritance, abstraction, and testability. I get the feeling that Spring is butting heads against the major app servers except for WebLogic. Spring absolutely needs an app server to provide non-functional features such as a thread model and integration to JEE containers. But now there seems to be a proliferation and lack of coordination of configuration and context strategies. Spring supports its own new XML namespaces to allow for a simpler and extensible domain language. XBeans does the same but primarily under the Apache/Codehaus suite. JBoss uses JMX, JNDI and their own aspects. And now there is movement towards OSGi. Springs contexts can work with the others in cases but the others aren't running to provide transparency to Spring except good old WebLogic. Gotta give it to BEA for doing a great job as an integrator of orthogonal JSR-centric and defacto standards. A bigger trend seems to be the inability for shops to migrate to JDK1.5, JPA, or aspects. IBM is ofcourse dragging its big blue ass on features that really hog tie a lot of people. Spring alas offers a bridge to features so many can't use. My hunch is that Spring is backdooring it into the app server market. They are working from the object on out as opposed to the thread model on in. Hot deployment may come next. In any case, Spring is great stuff. Congratulations.
  51. Re: Reviews[ Go to top ]

    Andrew
    I get the feeling that Spring is butting heads against the major app servers except for WebLogic.
    Obviously BEA's support for Spring is well-known, as in the fact that they are building parts of their next generation of WebLogic on Spring: see the joint press release from Interface21 and BEA. However, most app server vendors are in fact positive about Spring. For example, see the following recent Oracle press release about the release of Spring 2.0, which I believe Mike Keith (who of course is a senior Oracle employee) linked to in this thread already. Let me quote from that release:
    "The recently reached milestone of one million downloads of the Spring Framework is a testament to its value for developers and its ability to simplify the development process," said Dennis Leung, vice president, Oracle Fusion Middleware development, Oracle.
    This is a clear endorsement from a senior executive responsible for a critical middleware project at Oracle. And we are not talking about one individual: SCA is a high profile direction for Oracle middleware (and that of other large companies) and Oracle's SCA strategy heavily involves Spring. Let me quote from a blog by Greg Pavlik, a senior software technologist at Oracle and one of the Oracle reps on the SCA consortium:
    4) Oracle's SOA Suite will leverage SCA as the basic description unit of the integration technologies in Fusion middleware, as Thomas Kurian pointed out at JavaOne this year. With the momentum that our applications and middleware businesses are gathering, this is going to be a fantastic showcase of what we're doing. I've had a lot of fun working on the service fabric. It's also built using Spring, which has been a blast to use. More on that subject.... 5) Last, and from a Java programmers perspective, some very interesting news: there is now a Spring integration that allows Spring-based applications to tie in directly to an SCA-based SOA environment. As Spring becomes a de facto standard in many organizations for building J2EE applications, we're opening the door to transparent SCA-based integration for these investments. Plus now there's a practical open source story for Java developers to get on board with SCA without worrying about new learning curves or lots of new constructs. With Spring, it can be just POJOs: turtles all the way down. I had a lot of folks ask me directly about Java programming and SCA. Spring is a great answer.
    So the message from Oracle is pretty clear: they are encouraging their customers to use Spring and they are using it in key products. IBM have already emphasized the integration between Spring and Geronimo/WebSphere CE:
    "Certification of Spring by Interface21 on WebSphere Application Server Community Edition provides our customers with additional confidence in their decision to utilize the Spring framework to build applications", said Scott Cosby, Gluecode transition executive, IBM WebSphere Software.
    That quote is here. We are hopeful of a similar certification for Spring 2.0 on WebSphere. So, both BEA and Oracle are extremely supportive of Spring, and involving Spring in their middleware strategies, and IBM have started to make positive moves towards Spring. There is no necessary conflict between Spring and app servers, and no conflict between Spring and app server vendors. And it's not hard to see why app server vendors are taking Spring seriously. Spring has a market presence they cannot ignore--and it makes many of their customers happy, and happy customers are good. BEA, for example, surveyed their customer base before announcing Spring support last year, and learnt that a large proportion of their customers used Spring and wanted Spring support. And a recent public poll on BEA's Dev2Dev web site showed that 64% of respondents were using Spring:
    The Poll that ended this week, we asked "Are you building applications with IoC/dependency injection?" 64% of those that responded indicated that they were, with Spring. A further 10% are also using IoC with a different framework, while only 26% have yet to take up IoC. So, most of our readers (who bother to use the poll) use IoC!
    It would simply be bad business for application server vendors to ignore numbers like that. Well run companies, big or small, listen to customers. Rgds Rod
  52. Re: Reviews[ Go to top ]

    Andrew To comment on your other point:
    Spring absolutely needs an app server to provide non-functional features such as a thread model and integration to JEE containers.
    This is not strictly speaking accurate. If you want services such as a distributed transaction coordinator, a robust message queue etc. you are normally best to use an app server and Spring is designed to integrate well into an app server environment via Java EE APIs and can even use deeper integration on some platforms, like WebLogic. If you only want one of these things you could consider using a standalone transaction coordinator or message queue, for example. Several of them are designed to allow configuration by Spring. A good many applications, especially in the financial space, use a message queue without an app server and Spring 2.0 includes important features to support this common usage model. Many web applications require only a web container such as Tomcat or Jetty. Spring provides the same programming model in all cases, so you gain greatly here by avoiding the need to change your Java code if you subsequently want to migrate from Tomcat to WebLogic, for example. There are also many standalone applications that use only Spring. For example, one of Interface21's more unusual clients is a resource exploration company that processes vast amounts of seismic data using a Spring-based application with no other container. And then of course Spring can be used for rich client development. See the Spring Rich Client Project. Bottom line: Spring is not designed to replace an app server. It aims to provide the most productive and flexible component model available, in whatever environment is appropriate for your needs. There is no conflict with using Spring inside an app server, and vendors such as BEA and Oracle endorse this. Rgds Rod
  53. Re: Reviews[ Go to top ]

    Andrew

    To comment on your other point:
    Spring absolutely needs an app server to provide non-functional features such as a thread model and integration to JEE containers.
    This is not strictly speaking accurate. If you want services such as a distributed transaction coordinator, a robust message queue etc. you are normally best to use an app server and Spring is designed to integrate well into an app server environment via Java EE APIs and can even use deeper integration on some platforms, like WebLogic. If you only want one of these things you could consider using a standalone transaction coordinator or message queue, for example. Several of them are designed to allow configuration by Spring. A good many applications, especially in the financial space, use a message queue without an app server and Spring 2.0 includes important features to support this common usage model.

    Many web applications require only a web container such as Tomcat or Jetty. Spring provides the same programming model in all cases, so you gain greatly here by avoiding the need to change your Java code if you subsequently want to migrate from Tomcat to WebLogic, for example.

    There are also many standalone applications that use only Spring. For example, one of Interface21's more unusual clients is a resource exploration company that processes vast amounts of seismic data using a Spring-based application with no other container. And then of course Spring can be used for rich client development. See the Spring Rich Client Project.

    Bottom line: Spring is not designed to replace an app server. It aims to provide the most productive and flexible component model available, in whatever environment is appropriate for your needs. There is no conflict with using Spring inside an app server, and vendors such as BEA and Oracle endorse this.

    Rgds
    Rod
    And for a threading model, you can use Spring to instantiate an instance of java.util.concurrent.ThreadPoolExecutor. I do this to provide a thread pool for background tasks and event handling in my app... The front-end threads are managed by the servlet container (Tomcat, usually) and my backend threads are managed by the ThreadPoolExecutor.
  54. Re: Reviews[ Go to top ]

    Bottom line: Spring is not designed to replace an app server.
    I think the jury is still out on this one. Spring certainly duplicates some functions already provided by JavaEE appservers. Declarative transactions is one example; same semantics but different spellings. The functions in Spring that build on JavaEE standard functions are more interesting, and it will be fun to see how this plays out over time. Rod and I have disagreed on this topic in a previous TSS thread, and I don't expect that to change. Whatever...
  55. Re: Reviews[ Go to top ]

    Bottom line: Spring is not designed to replace an app server.

    I think the jury is still out on this one. Spring certainly duplicates some functions already provided by JavaEE appservers. Declarative transactions is one example; same semantics but different spellings. The functions in Spring that build on JavaEE standard functions are more interesting, and it will be fun to see how this plays out over time.

    Rod and I have disagreed on this topic in a previous TSS thread, and I don't expect that to change. Whatever...
    How exactly can you disagree? He designed the thing. He knows that it was designed to do. You may as well argue that with a artist about the meaning of his work or a writer about what he meant by a particular passage.
  56. Re: Reviews[ Go to top ]

    Bottom line: Spring is not designed to replace an app server.

    I think the jury is still out on this one.
    Are you implying that the author of the framework is misleading us on purpose, and has a hidden agenda of world domination of the app server market through Spring, presented to us unsuspecting humans as "only" a framework? Or were you just kidding?
  57. Re: Reviews[ Go to top ]

    Randy
    Spring certainly duplicates some functions already provided by JavaEE appservers. Declarative transactions is one example; same semantics but different spellings.
    Let me explain the history of this example. First, note that we're talking about a particular function (part of a component model), rather than the underlying service itself in the case of JTA/JTS. The difference between component model and platform is different. In mid 2003 Spring pioneered sophisticated declarative transaction management for POJOs, requiring no special non-Java contract and no dependence on Spring APIs. This worked in a variety of environments: over JTA, in a web container without a JTA implementation or in a standalone environment. EJB is the only Java EE technology to provide declarative transaction management. At that time EJB was far from a POJO-based specification. Each EJB required several runtime artifacts. Furthermore, Spring introduced significantly greater sophistication regarding declarative transaction model than the EJB 2.x model. For example, Spring introduced the notion of rollback rules, where it was possible to specify declaratively whether or not an exception should cause rollback. This avoided the need to catch exceptions and call setRollbackOnly() before rethrowing: a common source of pointless code and programmer error. Today, EJB 3 provides a closer analog to what Spring provides in this area. (Note that it significantly postdates Spring, and it's hard to imagine it would look anything like the same without Spring.) However, the EJB 3 model requires per-bean XML configuration or annotations to make beans transactional. Spring, OTOH can use either an annotation, more concise XML configuration, or an AspectJ pointcut expression to identify transactional objects in the context of an application architecture. The EJB 3.0 notion of an "application exception" is not as flexible as Spring's rollback rules (which allow per use case configuration, which is important in my experience), although presumably it owes something to Spring's work in this area. And declarative transaction management can of course only be applied to EJBs, which arguably are not true POJOs: for example, they exhibit various pooling and exception translation behavior that is not customizable and departs from usual Java expectations. And of course, this option is simply not available to the significant user population on platforms that cannot use Java 5 or a Java EE 5 implementation. This includes the vast majority of enterprise customers, and will for some time. For example, the whole WebSphere user base, which is current one of the biggest in the industry. And Spring provides a mature, proven component model, with no need to try a costly upgrade to a bleeding application edge server just to get a decent programming model. The Pitchfork project (an add-on for Spring 2.0 that Spring users can use if they want, again in any environment) enables Spring to handle EJB3 TransactionAttribute annotations with relatively little code, because Spring offers a superset of the EJB 3.0 semantics. The reverse would be harder. The "same semantics" is also a moot point. Spring provides declarative transaction management in any environment, as I've mentioned, so it's more general than Java EE and JTA. A surprisingly large number of applications use Java but not JavaEE. (For example, I have recently spoken to two top investment banks who do not use app servers, and made this choice independently of whether to use Spring.) And Spring still provides a more sophisticated model for transactions than EJB3, including supported for emulating nested transactions where possible.
    Rod and I have disagreed on this topic in a previous TSS thread, and I don't expect that to change
    I enjoy our debates and believe that all too often technology companies become myopic because they believe their own headlines. Good discussion and reasoned alternate opinions are always good to challenge beliefs; constructive criticism is always welcome by the Spring team and Interface21. Rgds Rod
  58. Re: Reviews[ Go to top ]

    "Spring is for" the simplification of, and the insulation of programmers from the most error prone portions of, a boatload of common Java usage patterns.


    So, some kind of IDE Wizard could replace Spring?
    You are soooooooo very close, but you've got it just a little bit backwards. Spring is fairly good at removing the 90% of code that you would have had your IDE Wizard generate back in 2001 / 2002. The second leg of the Spring triumvirate is that the 10% that you have left is likely tied to absolutely nothing (including to Spring itself) because it is a receiver of state and invocation, and not a manager thereof. As a result, it is easy to deploy into a Java EE environment, or to be used (or tested) outside of that environment. The third leg is that Spring provides some good class libraries that allow you to tie to the Spring API in order to make other APIs (such as JDBC) more palatable to application developers. In this respect, it's little different from various Apache class libraries (except generally simpler and more elegant) or libs like the SQL helpers in iBatis. The "danger" of the third leg is getting tied in to Spring, so if that scares you, then keep writing and maintaining your own class libraries, or allowing that IDE Wizard to create reams of code for you to maintain. Spring is not perfect. Any XML configuration is naturally annoying, no matter how simple. Spring doesn't solve everything. It's definitely getting bigger with every release. Nonetheless, it is relatively pragmatic, elegant and clean compared to the alternatives that it tends to replace and/or simplify. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  59. Re: Reviews[ Go to top ]

    You are soooooooo very close, but you've got it just a little bit backwards. Spring is fairly good at removing the 90% of code that you would have had your IDE Wizard generate back in 2001 / 2002.
    ...
    The "danger" of the third leg is getting tied in to Spring, so if that scares you, then keep writing and maintaining your own class libraries, or allowing that IDE Wizard to create reams of code for you to maintain.
    But won't you have to maintain tons of XML too? Isn't better to maintain Java code instead? How replacing "reams of code generated by Wizards" with "tons of XML created for Spring" is better? Isn't it all "reams of something" in the end?
    Spring is not perfect. Any XML configuration is naturally annoying, no matter how simple. Spring doesn't solve everything. It's definitely getting bigger with every release. Nonetheless, it is relatively pragmatic, elegant and clean compared to the alternatives that it tends to replace and/or simplify.
    What would be the alternatives?
  60. Re: Reviews[ Go to top ]

    Spring is uncommunicable. I am still to meet a single person that can summarize in words what Spring is for.
    When I describe Spring to someone who's never heard of it before, I first make the point that the core of Spring is a container, and there's a whole bunch of other stuff you may or may not use. To describe the container, I give an example of what it typically replaces, which is usually a set of custom factory classes and a homegrown config framework. So in the simplest sense, the Spring container is just a factory and config framework, and it prevents you from having to write/test/document any of that yourself. I've seen plenty of projects (those that use EJBs and those that don't) where developers have written their own factory/config framework, and it's usually messy and undocumented, so replacing that kind of junk with the Spring container is reason alone for me to use Spring. The DI aspect of the container is the real value, in that your code is unaware of the Spring container and thus not dependent on it. This is in contrast to typical factory usage, which is usually of the form "MyClass cl = MyFactory.newMyClass()", which ties the code to the factory infrastructure, thus making it harder to reuse. Of course, the value here is true of any DI container (Pico, Hivemind, etc.). So that's the Spring container in a very simple sense. Everything else - the JDBC support, the Hibernate support, Spring MVC, Spring AOP, etc etc. - is completely optional, and you can read the documentation on each package to find out if it's of any value to you. Now that doesn't seem too hard to understand. In fact, you can read a much better description in section 1.1 of the Spring manual, along with a pretty picture. Why not put the effort in of doing that? Then you can save yourself the effort of writing lazy critiques about how you can't understand Spring because you've never bothered to read the manual.
  61. Re: Reviews[ Go to top ]

    To describe the container, I give an example of what it typically replaces, which is usually a set of custom factory classes and a homegrown config framework. So in the simplest sense, the Spring container is just a factory and config framework, and it prevents you from having to write/test/document any of that yourself. I've seen plenty of projects (those that use EJBs and those that don't) where developers have written their own factory/config framework, and it's usually messy and undocumented, so replacing that kind of junk with the Spring container is reason alone for me to use Spring.
    There has been a lot of talk about DSLs lately, and the concept of DSLs and it promotes the use of specific solutions for certain domains. Wouldn't something more specific be easier than a big framework such as Spring?
    The DI aspect of the container is the real value, in that your code is unaware of the Spring container and thus not dependent on it. This is in contrast to typical factory usage, which is usually of the form "MyClass cl = MyFactory.newMyClass()", which ties the code to the factory infrastructure, thus making it harder to reuse.
    If you have tons of XML for Spring, wouldn't it be tied to Spring anyway? Why XML "doesn't count" when considering being tied up? Isn't tons of XML "invasive"? In the sense of tying you to Spring every time more and consuming hours in maintenance? BTW, how can DI "eliminate" dependecies if they will be in the XML?
    Now that doesn't seem too hard to understand. In fact, you can read a much better description in section 1.1 of the Spring manual, along with a pretty picture. Why not put the effort in of doing that? Then you can save yourself the effort of writing lazy critiques about how you can't understand Spring because you've never bothered to read the manual.
    As a matter of fact I bothered reading the information in the website and couldn't see any logical reason to use it, architecturaly speaking. And because of the so much hyped "simpler" solutions and DSLs, wouldn't use Spring be in the wrong direction?
  62. DI and dependencies[ Go to top ]

    how can DI "eliminate" dependecies if they will be in the XML?
    Consider the use of JNDI to get a DataSource to get a JDBC Connection. Here's the code from the examples on the Apache web site: public void init() { try{ Context ctx = new InitialContext(); if(ctx == null ) throw new Exception("Boom - No Context"); DataSource ds = (DataSource)ctx.lookup( "java:comp/env/jdbc/TestDB"); if (ds != null) { Connection conn = ds.getConnection(); if(conn != null) { // // WOW!!! We got a Connection!!! // conn.close(); } } }catch(Exception e) { e.printStackTrace(); } } Now consider how you would do it in Spring: public void init(Connection conn) { if(conn != null) { // // WOW!!! We got a Connection!!! // } } As you can see, we've eliminated the dependencies on the JNDI being available and also on the DataSource, yet we haven't introduced any dependencies on Spring. In other words, the result is no longer tied to a Java EE server environment, and it is simpler, and it still works fine in Java EE. BTW I don't understand your repetitions of the phrase "tons of XML". Perhaps you have used Spring more than I have, and can tell me how much XML it would take to inject the Connection? Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  63. Re: DI and dependencies[ Go to top ]

    As you can see, we've eliminated the dependencies on the JNDI being available and also on the DataSource, yet we haven't introduced any dependencies on Spring.

    In other words, the result is no longer tied to a Java EE server environment, and it is simpler, and it still works fine in Java EE.
    It's not simpler and it wasn't elimited because you will have to configure it in the XML and provide a public setter for it. Besides the "different way of doing the same stuff" you just gave up on the OO encapsulation because of setters that shouldn't exist. With only OO it's possible to abstract such things via an API and use it places other than the Java EE container.
    BTW I don't understand your repetitions of the phrase "tons of XML". Perhaps you have used Spring more than I have, and can tell me how much XML it would take to inject the Connection?
    Go look for another insecure-developer type. Even if I didn't know it copying and pasting from websites is easy. What does it proof? Nothing. Anyway, after all these "explanations" I believe Spring is the #1 way of scaring people away from Java. In the best of all cases it doesn't fix nor creates any problem, in the worst case it build an enormous complexity tower for the developers to deal with.
  64. The pattern is somewhat like this: - Wow DI is cool, Spring solves a great "problem". And the user drawns himself in a sea of complexity. One day he checks out that hype people have talking so much and try a dynamic language, then: - Hey, I can do that DI thing (bad design) so easily in this! I don't need to specify types and the classes are open, so I can just add stuff. And there's no XML. Look, in Java you need a whole framework to do this. First: Spring a complex non-solution to the simple non-problem of DI. Second: You don't need Spring in order to build scalable and reliable code in Java. The Spring king has no clothes.
  65. The pattern is somewhat like this:

    - Wow DI is cool, Spring solves a great "problem".

    And the user drawns himself in a sea of complexity. One day he checks out that hype people have talking so much and try a dynamic language, then:

    - Hey, I can do that DI thing (bad design) so easily in this! I don't need to specify types and the classes are open, so I can just add stuff. And there's no XML. Look, in Java you need a whole framework to do this.

    First: Spring a complex non-solution to the simple non-problem of DI.
    Second: You don't need Spring in order to build scalable and reliable code in Java.

    The Spring king has no clothes.
    I shouldn't be wasting my time, but I'll bite... Why listen to anything you have to offer on the subject? You've stated yourself that you neither understand Spring nor know anyone who understands it. So any opinion you have on the subject is uninformed speculation at best. Personally, I hope you never use it. Everything someone like you writes something, I get paid to fix it, so have at it! I'm looking to upgrade my house.
  66. Why listen to anything you have to offer on the subject? You've stated yourself that you neither understand Spring nor know anyone who understands it.

    So any opinion you have on the subject is uninformed speculation at best. Personally, I hope you never use it. Everything someone like you writes something, I get paid to fix it, so have at it! I'm looking to upgrade my house.
    Wow, TheServerSide bullies got offended by a critique! Hahaha You are a joke, are you implying that only Spring developers do "good code" and everyone else in the planet do "bad code" because they don't know the "wonders of Spring"??? This kind of of religious loser is the moron that believes to be the greatest programmer on earth, with all the "cool tricks", and then other people have to live with the big pile of spaghetti created afterwards.
  67. Why listen to anything you have to offer on the subject? You've stated yourself that you neither understand Spring nor know anyone who understands it.

    So any opinion you have on the subject is uninformed speculation at best. Personally, I hope you never use it. Everything someone like you writes something, I get paid to fix it, so have at it! I'm looking to upgrade my house.


    Wow, TheServerSide bullies got offended by a critique! Hahaha

    You are a joke, are you implying that only Spring developers do "good code" and everyone else in the planet do "bad code" because they don't know the "wonders of Spring"???

    This kind of of religious loser is the moron that believes to be the greatest programmer on earth, with all the "cool tricks", and then other people have to live with the big pile of spaghetti created afterwards.
    Sure. You've admitted you don't understand Spring, so you clearly don't know if it is cool or not. You are quick with the insults, though, aren't you? Why do you spend as much time reading up on the subject matter?
  68. Re: DI and dependencies[ Go to top ]

    It's not simpler and it wasn't elimited because you will have to configure it in the XML and provide a public setter for it. Besides the "different way of doing the same stuff" you just gave up on the OO encapsulation because of setters that shouldn't exist.

    Exposing your collaborators is a good OO practice. If it isn't a collbarator, ie the actual implementation is choosen by the object itself and is an internal details, then just use a protected factory method instead of DI. DI isn't the remedy to every creation problem. The "push" model has its use and its limitations. Sometimes the "pull" approach is better.


    With only OO it's possible to abstract such things via an API and use it places other than the Java EE container.
    I hope you realize the amount of work it takes.

    BTW I don't understand your repetitions of the phrase "tons of XML". Perhaps you have used Spring more than I have, and can tell me how much XML it would take to inject the Connection?


    Go look for another insecure-developer type. Even if I didn't know it copying and pasting from websites is easy. What does it proof? Nothing.

    Anyway, after all these "explanations" I believe Spring is the #1 way of scaring people away from Java. In the best of all cases it doesn't fix nor creates any problem, in the worst case it build an enormous complexity tower for the developers to deal with. Still drawing conclusions without trying the product?
  69. Re: DI and dependencies[ Go to top ]

    DI isn't the remedy to every creation problem. The "push" model has its use and its limitations. Sometimes the "pull" approach is better.
    It's nice that some people are admiting that DI (and Spring) isn't a magic wand that makes your code "scalable, reliable and everything else".
    I hope you realize the amount of work it takes.
    And the work of maintaining separate XML files? The point I am trying to make is that people here think things magically disappear, when in fact there's XML for that code you didn't write in Java that needs to be maintained too.
  70. Re: DI and dependencies[ Go to top ]

    I hope you realize the amount of work it takes.


    And the work of maintaining separate XML files? The point I am trying to make is that people here think things magically disappear, when in fact there's XML for that code you didn't write in Java that needs to be maintained too.
    I was referring to abstracting an API (for instance transactions). You said it was easy to do using good OO skills. Well I totally disagree, it's very hard to design a neutral API that is able to work using an Hibernate transaction, a JTA transaction, ...
  71. Re: DI and dependencies[ Go to top ]

    I was referring to abstracting an API (for instance transactions). You said it was easy to do using good OO skills. Well I totally disagree, it's very hard to design a neutral API that is able to work using an Hibernate transaction, a JTA transaction, ...
    Ok, how many times a system will be updated in a year for using different types of abstraction? You see, more is not better when it comes to abstractions. If you need X, why would you bother writing an API for the whole alphabet? This is abstraction leak. Besides, using OO only it's possible to make the life of the developer easier in the future, in the remote case of changing such things. You don't need to implement everything right away if it's not needed by your project.
  72. Re: DI and dependencies[ Go to top ]

    I was referring to abstracting an API (for instance transactions). You said it was easy to do using good OO skills. Well I totally disagree, it's very hard to design a neutral API that is able to work using an Hibernate transaction, a JTA transaction, ...


    Ok, how many times a system will be updated in a year for using different types of abstraction?

    You see, more is not better when it comes to abstractions. If you need X, why would you bother writing an API for the whole alphabet? This is abstraction leak.

    Besides, using OO only it's possible to make the life of the developer easier in the future, in the remote case of changing such things. You don't need to implement everything right away if it's not needed by your project.
    For you, it seems, not much. Where I work, we tend to crank out multiple small to medium projects per year across several small groups of developers. I work on probably several projects per year. Our customers want to run on anything from Tomcat to Websphere and on Java 1.4 or 1.5. Using Spring and Hibernate(and sometimes JDBC) we support all of this on a common framework of code. So I can say that more is better for us. In fact, I had to port an app from Oracle 9ias to JRun 4 to Tomcat during one dev cycle. All I had to change was a single entry in a single XML file. In addition, with Spring you don't get your so-called "abstraction leak" because it is already written. What is "abstraction leak" for you, to me, is just...Wednesday.
  73. Re: DI and dependencies[ Go to top ]

    What is "abstraction leak" for you, to me, is just...Wednesday.
    For everyone else is "badly designed software". I follow the K.I.S.S. principle, too bad in this area some like to overcomplicate things.
  74. Re: DI and dependencies[ Go to top ]

    What is "abstraction leak" for you, to me, is just...Wednesday.


    For everyone else is "badly designed software". I follow the K.I.S.S. principle, too bad in this area some like to overcomplicate things.
    No, your needs are simpler than mind. The problem is you that project your simplified needs onto others.
  75. Re: DI and dependencies[ Go to top ]

    I was referring to abstracting an API (for instance transactions). You said it was easy to do using good OO skills. Well I totally disagree, it's very hard to design a neutral API that is able to work using an Hibernate transaction, a JTA transaction, ...


    Ok, how many times a system will be updated in a year for using different types of abstraction?

    You see, more is not better when it comes to abstractions. If you need X, why would you bother writing an API for the whole alphabet? This is abstraction leak.

    Besides, using OO only it's possible to make the life of the developer easier in the future, in the remote case of changing such things. You don't need to implement everything right away if it's not needed by your project.
    Well I don't know what kind of systems you develop, but in my experience it happens more often than you think. Having a architecture that scale up or down is something very important. Testing your application outside of the container is also very important... You see using Spring, I change one setting and voila I am using a different transaction implementation, something very useful in my experience especially to port an application or testing it outside of the container.
  76. Re: DI and dependencies[ Go to top ]

    I was referring to abstracting an API (for instance transactions). You said it was easy to do using good OO skills. Well I totally disagree, it's very hard to design a neutral API that is able to work using an Hibernate transaction, a JTA transaction, ...


    Ok, how many times a system will be updated in a year for using different types of abstraction?

    You see, more is not better when it comes to abstractions. If you need X, why would you bother writing an API for the whole alphabet? This is abstraction leak.

    Besides, using OO only it's possible to make the life of the developer easier in the future, in the remote case of changing such things. You don't need to implement everything right away if it's not needed by your project.


    Well I don't know what kind of systems you develop, but in my experience it happens more often than you think. Having a architecture that scale up or down is something very important. Testing your application outside of the container is also very important... You see using Spring, I change one setting and voila I am using a different transaction implementation, something very useful in my experience especially to port an application or testing it outside of the container.
    The scale down is very important. I've used the Spring/Hibernate/Struts stuff for apps as small as two pages. In fact, such things are great for introducing new people to the architecture without hitting them will larger apps. The consistency and reuse is invaluable.
  77. Re: DI and dependencies[ Go to top ]

    It's not simpler and it wasn't elimited because you will have to configure it in the XML and provide a public setter for it. Besides the "different way of doing the same stuff" you just gave up on the OO encapsulation because of setters that shouldn't exist.
    With 5 minutes research, you would have noticed that Spring supports constructor injection as well as setter injection, and has done so for around 3 years. You do not need to provide "setters that shouldn't exist"; you can use constructors taking arguments. For example, you can inject final fields, as an example I showed earlier in this thread does, if your object is immutable. Also, you do not need to configure every dependency in XML; Spring provides an optional feature called "autowiring" that enables the container to use introspection to determine dependencies automatically. Rgds Rod
  78. Re: DI and dependencies[ Go to top ]

    It's not simpler and it wasn't elimited because you will have to configure it in the XML and provide a public setter for it. Besides the "different way of doing the same stuff" you just gave up on the OO encapsulation because of setters that shouldn't exist.
    I showed a Connection parameter added to the method. What else do you need? You don't need any setters.
    With only OO it's possible to abstract such things via an API and use it places other than the Java EE container.
    Yes, but Java EE already does that using "OO". JNDI abstracts named resource lookup. DataSource abstracts connection factories. Nonetheless, comparing the code snippets that I posted makes it quite clear just how much extra "OO" one needs to implement the same functionality, and how many extra abstractions (e.g. JNDI) that one needs outside of the Java EE server environment for the same code to run. Or you could just make your own framework .. but if you're going to do that, why not just use something that already exists? Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  79. Although I've read a bunch on the subject, I haven't done any development with Spring so I coming from a somewhat ignorant standpoint. When you say that "we haven't introduced any dependencies on Spring," do you mean that the code will now run without Spring? Is that true with all dependency injection? Will all dependency injection code run fine without Spring? I'm very skeptical of such a claim. It seems like you're hiding something.
  80. When you say that "we haven't introduced any dependencies on Spring," do you mean that the code will now run without Spring? Is that true with all dependency injection? Will all dependency injection code run fine without Spring?
    Dependency Injection (DI) is designed to remove explicit lookup. Explicit lookup requires an API; with DI language constructs such as setter methods or constructors are used instead. So, for example: public class Injected { private final Foo foo; private final Bar bar; public Injected(Foo foo, Bar bar) { this.foo = foo; this. bar = bar; } // business methods omitted... } Or this style: public void setFoo(Foo foo) { this.foo = foo; } Neither form depends on the container in use. Thus you could use both with Spring, but could use both without Spring also. And, of course, you probably already have a lot of existing code written without any concern for DI that can work fine with a sophisticated container. Spring also supports scenarios like this, using a static factory method: public class Injected { public static Injected meaningfulName(Foo foo, Bar bar) { return new Injected(foo, bar); } private final Foo foo; private final Bar bar; private Injected(Foo foo, Bar bar) { this.foo = foo; this. bar = bar; } // business methods omitted... } Bottom line: you can use good Java code with a good DI container. And you can write code to use with a DI container that is usable without it. Of course a sophisticated container will also provide a range of advanced features, such as the ability to inject proxies transparently to offer dynamic behavior etc, and Spring leads the way in this. For example, Foo could be transactional (transparently) and Bar could be a remote service. All these objects could optionally be exposed for JMX management without any use of Spring APIs or changes to Java code. None of these examples imports a single Spring class. Of course, Spring also provides a range of valuable class libraries (such as Spring JDBC), but you only need to use them where they make life demonstrably simpler. We in the Spring team have gone to great pains to try to close off corner cases where you need to depend on Spring for configuration. Thus most of your code is not tied to Spring. We don't aim to lock people in through imports, but hope to ensure that the value proposition Spring provides is so compelling that people will want to use it by choice :-) Btw explicit dependence on APIs also makes it hard for runtime environments to evolve. We could make Spring 2.0 backward compatible fairly easily because most code in Spring applications does not depend on Spring. Rgds Rod
  81. Although I've read a bunch on the subject, I haven't done any development with Spring so I coming from a somewhat ignorant standpoint. When you say that "we haven't introduced any dependencies on Spring," do you mean that the code will now run without Spring? Is that true with all dependency injection? Will all dependency injection code run fine without Spring? I'm very skeptical of such a claim. It seems like you're hiding something.
    For the record, that's a pretty offensive statement. People tend to say things on forums that they would say to someone's face. Addressing your concern, I recently delivered a library that used Spring internally to a customers. They wanted assurances that they could use the code without Spring and after a short demo, they were convinced. Remember, at its heart, Spring is a factory. If you use new() to create all the objects and then say use the setters to configure the resulting objects, no you don't need Spring. If you, however, decide to use Spring's convenience classes, you will have some dependencies, but these can be hidden by interfaces and base classes. In our projects, you will see Spring in the following: 1) Web tiers base Actions because I inject some stuff into actions. This can be removed fairly easily and is hidden behind our dependency on Struts(which is going way, but it has been a great run...). 2) DAO base implemetation that uses Spring's Hibernate Template. But your child DAOs don't have as much as an import. 3) AOP Interceptors. A conscious decision to take advantage of Spring's AOP support. And this is only in the interceptor. We have Managers that are injected into the interceptors that do the real work and the managers don't have no dependencies on Spring.
  82. Remember, at its heart, Spring is a factory. If you use new() to create all the objects and then say use the setters to configure the resulting objects, no you don't need Spring.

    If you, however, decide to use Spring's convenience classes, you will have some dependencies, but these can be hidden by interfaces and base classes. In our projects, you will see Spring in the following:

    1) Web tiers base Actions because I inject some stuff into actions. This can be removed fairly easily and is hidden behind our dependency on Struts(which is going way, but it has been a great run...).

    2) DAO base implemetation that uses Spring's Hibernate Template. But your child DAOs don't have as much as an import.

    3) AOP Interceptors. A conscious decision to take advantage of Spring's AOP support. And this is only in the interceptor. We have Managers that are injected into the interceptors that do the real work and the managers don't have no dependencies on Spring.
    Almost forgot, I'm looking at Springs Velocity support and we do use the convinience email classes(hidden behind our implementation and interface similar to DAOs)
  83. I guess it's pretty easy to be offended around here. Sorry, no offense was intended. Anyway, my point was that your example and statement of no dependency seems misleading since the code won't run without Spring, as much as the counter-example won't run without JNDI. (i.e. you either have to rewrite the code, have Spring as part of your application, or have some other DI mechanism installed.) In addition, there apparently is some configuration code required to get the code to work that you aren't showing. (that's what I mean by hiding something) If that's true, then you didn't necessarily make the code simpler, you just moved it someplace else. Or am I misunderstanding something? I understand that the code will compile fine without Spring installed, but I doubt it will actually run - at least without reworking the code, adding code, or using some Spring replacement to make it run. Or am I completely missing the concept? Anyway, I'm still trying to understand how DI is better than using factories and interfaces - as far as dependencies are concerned. And isn't it to our benefit to have the compiler tell you that you're code won't run - e.g. no JNDI library found? Don't you lose that with DI?
  84. (i.e. you either have to rewrite the code, have Spring as part of your application, or have some other DI mechanism installed.)
    No, there is no direct dependency on Spring. Of course, you still need to wire the different beans together but at least if you want, you can set the collaborators by yourself and it will still work.
    In addition, there apparently is some configuration code required to get the code to work that you aren't showing. (that's what I mean by hiding something) If that's true, then you didn't necessarily make the code simpler, you just moved it someplace else. Or am I misunderstanding something?

    You have made the code simpler because you didn't have to program yet another factory and you have separated different concerns, ie business logic from objects creation and wiring.
    I understand that the code will compile fine without Spring installed, but I doubt it will actually run - at least without reworking the code, adding code, or using some Spring replacement to make it run. Or am I completely missing the concept?
    Of course, it won't work unless you inject some collaborators in your objects but this is also true when you use a factory (in contrast to using a service locator). Note that this is an advantage because your objets become more loosely coupled and therefore are more supple and testable.
    Anyway, I'm still trying to understand how DI is better than using factories and interfaces - as far as dependencies are concerned.
    Basically a DI container is a factory framework. No need to implement ad hoc factories, which can necessitate a substantial amount of work (cache, pooling, state management, configuration persistance, ...). This logic can become quite complex, so why reimplement it every time when you have a well tested framework providing it for free. So basically it should save you a lot of extra code if you were using a lot of factories. Here's one of the nicest introduction on the subject in my opinion : http://www.d-ross.org/index.cfm?objectid=2EC8FF78-EF49-4E45-CDFEF2DA7F393A25 Another extra benefit of using Spring DI container to instantiates your dependencies is that it can weave aspects in your objects in order to handle standard cross cutting concerns (transactions, security, remoting, ...) as well as more specific ones (audits, exception handling, ...) in a portable way (in a standard JVM, in a JEE container, ...).
    And isn't it to our benefit to have the compiler tell you that you're code won't run - e.g. no JNDI library found? Don't you lose that with DI?
    JNDI is also an indirection mechanism. You won't know if the dependency can be resolved or not until you actually run the program.
  85. Or am I misunderstanding something?
    You need to have an aha! moment. Think of constructing a JUnit unit test using setters to inject interface compatible mock objects into your POJO under test. So far no Spring, no ServiceLocator, and no InitialContext. The JUnit test is doing the injecting with no dependencies on external frameworks. At runtime, if you use one POJO that initializes a Spring context (this is the hidden part and only dependency) that handles the injecting you can get object nesting n-levels deep with no notion of Spring, ServiceLocators, or InitialContexts. Why role your own when you can use Spring.
  86. Although I've read a bunch on the subject, I haven't done any development with Spring so I coming from a somewhat ignorant standpoint. When you say that "we haven't introduced any dependencies on Spring," do you mean that the code will now run without Spring? Is that true with all dependency injection? Will all dependency injection code run fine without Spring? I'm very skeptical of such a claim. It seems like you're hiding something.
    But of course! The simpler implementation does not contain any logic for looking up connections -- it just _uses_ a connection. Therefore, someone / something has to look it up on its behalf. That preciseness of functionality that a piece of code is responsible for is a key tenet of good software engineering. The more coupled a piece of code is to various different APIs, and the more responsibilities that a particular piece of code has, the less re-usable (and flexible and portable) it becomes. By definition. So what I was hiding was the obviousness of the fact that the code that _uses_ the connection should not typically know _how to get_ that connection. It's just good software engineering practice. It's not about "DI". It's not about Spring. Spring and DI and Java EE servers and everything else under the sun is just a collection of tools in our toolbox that allow us to select the most effective solution to a problem at hand. By reducing the conglomeration of responsibilities and dependent interconnects (couplings) in a particular piece of code, we allow that software to be more easily compatible with a larger number of tools in our toolbox. Peace, Cameron Purdy Tangosol Coherence: The Java Data Grid
  87. Re: Reviews[ Go to top ]

    As a matter of fact I bothered reading the information in the website and couldn't see any logical reason to use it, architecturaly speaking.
    Trying it might be a better solution... Drawing conclusions on a product and worse arguing over it without actually trying it shows a lack of a scientific approach. There are tons of satisfied developers USING Spring on a day-to-day basic. Anyway, your argument over tons of XML is silly and prove you have never done any development using DI. You don't instantiate every damn object using Spring. You can still use the "new" operator. It is still perfectly legal! Use DI where it is appropriate. It saves you from writting ad hoc factories in lot of places.
  88. Re: Reviews[ Go to top ]

    Anyway, your argument over tons of XML is silly and prove you have never done any development using DI. You don't instantiate every damn object using Spring. You can still use the "new" operator. It is still perfectly legal! Use DI where it is appropriate. It saves you from writting ad hoc factories in lot of places.
    You are missing the point. I never said you needed to instantiate every single object, but moving code from Java to XML, it doesn't matter how much, is not good.
  89. Re: Reviews[ Go to top ]

    It's not simpler and it wasn't elimited because you will have to configure it in the XML and provide a public setter for it. Besides the "different way of doing the same stuff" you just gave up on the OO encapsulation because of setters that shouldn't exist.
    First you stated that you did not have any experience developing with Spring, and now you're suddenly a Spring critique expert? Almost every single statement in your comment above is incorrect, because: 1) you do not have to configure it in XML 2) You do not have to use setters A little more throrough investigation of the framework would have made you avoid making those two incorrect assumptions.
    I never said you needed to instantiate every single object, but moving code from Java to XML, it doesn't matter how much, is not good.
    "doesn't matter how much"? Really? So, it's not simply an "XML-hell" problem, as you were stating repeatedly earlier, just an XML-problem? So we shouldn't configure anything in XML, and put everything in code?
  90. Re: Reviews[ Go to top ]

    Anyway, your argument over tons of XML is silly and prove you have never done any development using DI. You don't instantiate every damn object using Spring. You can still use the "new" operator. It is still perfectly legal! Use DI where it is appropriate. It saves you from writting ad hoc factories in lot of places.


    You are missing the point. I never said you needed to instantiate every single object, but moving code from Java to XML, it doesn't matter how much, is not good.
    You can configure Spring using Java instead of XML. So what's your point again?
  91. Re: Reviews[ Go to top ]

    You can configure Spring using Java instead of XML. So what's your point again?
    My point is: - There will be unnecessary layers of complexity; - There will be dependence on Spring; - The lines of code that would "save" aren't really saved, just hidden somewhere else; - With DI you lose in maintainability and readability because you can't tell exactly what is going on just by looking at the code, you need to look on several places;
  92. Re: Reviews[ Go to top ]

    You can configure Spring using Java instead of XML. So what's your point again?


    My point is:

    - There will be unnecessary layers of complexity;
    - There will be dependence on Spring;
    - The lines of code that would "save" aren't really saved, just hidden somewhere else;
    - With DI you lose in maintainability and readability because you can't tell exactly what is going on just by looking at the code, you need to look on several places;
    I'm looking at my Spring application, and I don't see any "unnecessary layers of complexity"...Spring is modular, I only have to use the parts that I need. So, where would those mysterious layers be, specifically? And since you became a Spring expert all of a sudden maybe you could give me a concrete example of Spring code with those unavoidable "unnecessary layers", or lines of code that "aren't really saved, just hidden somewhere else". As for dependency on Spring, The framework is largely non-invasive. This is actually one of its main benefits, thanks in part to DI. It is painfully obvious that for some reason(s), you chose to comment on a subject without having bothered to read at least some documentation on it.
  93. To DI for[ Go to top ]



    My point is:

    ... With DI you lose in maintainability and readability because you can't tell exactly what is going on just by looking at the code, you need to look on several places;
    Wow. That statement is so '70s. I've got ABBA in my head. I want to see your tightly coupled, monolithic COBOL code base. Sounds like procedural code to me Mr. Disco Duck. I recommend you buy one of Rod Johnson's most excellent books or even Pojos in Action. Rebecca Wirfs-Brock is good too. You need to get back to your inner design child to understand responsibility, modularization, and abstraction. Wax on wax off. You will need to wire things together somehow. Spring is your path to happiness. There are other paths but they will offer you no peace. And your resume won't look so hot either. I feel your pain and it's OK to cry.
  94. Re: To DI for[ Go to top ]

    Wow. That statement is so '70s. I've got ABBA in my head. I want to see your tightly coupled, monolithic COBOL code base. Sounds like procedural code to me Mr. Disco Duck.

    I recommend you buy one of Rod Johnson's most excellent books or even Pojos in Action. Rebecca Wirfs-Brock is good too. You need to get back to your inner design child to understand responsibility, modularization, and abstraction. Wax on wax off. You will need to wire things together somehow. Spring is your path to happiness. There are other paths but they will offer you no peace. And your resume won't look so hot either.

    I feel your pain and it's OK to cry.
    This is the kind of fanatical statement we, sadly, see so often on the internet. People incapable of understanding OO and abstraction, and other ways of abstracting a domain as well, and how to build modular code, etc, firmly believing that Spring is the only way to "correct code". The concept of DI is flawed not because it is supposedly modular, but because makes the code less understandable by splitting it up in an unnatural way across different languages (Java and XML), and, unlike the marketing, it doesn't elimitate anything, it just hides it. OO takes care of abstracting things pretty well, in an easily readable, debuggable pieces of code, classes, APIs, libraries, etc. BTW, Spring users use SOP, Spring Oriented Programming, and have a "slang" of their own. Do you "wire" things up? WTF!
  95. Re: To DI for[ Go to top ]

    The concept of DI is flawed not because it is supposedly modular, but because makes the code less understandable by splitting it up in an unnatural way across different languages (Java and XML), and, unlike the marketing, it doesn't elimitate anything, it just hides it
    It eliminates the need to implement factories, dynamic proxies, etc which is a lot of code in my case.
  96. Re: Reviews[ Go to top ]

    I think you don't know exactly what it is for sure and as a result are criticizing it pretty unjustly (and incoherently). I think if you took the time to understand what it is and what it does, you'd find it useful.


    Spring is uncommunicable. I am still to meet a single person that can summarize in words what Spring is for.

    Frankly, the idea of "Spring the #1 way of scaring people away from Java" is about as ironic a statement as could be imagined given Spring's origins and what it was intended to fix.


    Sad but true.
    No offense, but that says more about the people you know and assoicate with than what Spring is. I'll bet the people you hang with cannot drop a tranny or remove an appendix, but there are thousands of people who can. I've summarized Spring plenty of times to people. The fact is that *Thiago* doesn't understand Spring.
  97. Re: Reviews[ Go to top ]

    Spring is uncommunicable. I am still to meet a single person that can summarize in words what Spring is for.
    Since there are no shortage of good presentations of that framework, someone trying to make sense of your statement would end up with the unfortunate conclusion that you may be unwilling or unable to make a single minimalistic effort to understand it.
  98. Spring essentials[ Go to top ]

    Spring is uncommunicable. I am still to meet a single person that can summarize in words what Spring is for.
    Perhaps this can help: http://www.theserverside.com/news/thread.tss?thread_id=42460 BEJUG has taken the time to prepare put an intro session online; there have been many positive reactions to this. Although this was for Spring 1, I guess most things are still valid. If you prefer reading, try this article. It may be a bit extreme use of Spring for some, but it shows again what it can do. Disclaimer: this represents my personal view on Spring. But still, I think it is the essence.
  99. Corrected URL[ Go to top ]

    Perhaps this can help: http://www.theserverside.com/news/thread.tss?thread_id=42460
    Apologies, the URL for the session is: http://media.techtarget.com/tss/BeJUG/J2EEAppsSpring/player.html
  100. Re: Reviews[ Go to top ]

    Why creating tons of XML is a good thing? Why taking things from Java code to XML is a good thing? Why creating such overhead is a good thing?

    I have a theory, Spring the #1 way of scaring people away from Java.
    It's been repeated hundreds of times, but if you hate XML so much, you can always write simple Java code instead. I have a theory too - Effort is the #1 way of scaring people away from talking intelligently about something. Going to a website and reading some documentation constitutes effort, and I'm sorry that it is such an obstacle for you.
  101. Re: Reviews[ Go to top ]

    I have a theory, Spring the #1 way of scaring people away from Java.
    Good. I wouldn't want to team up with that particular kind of people you're refering to anyway. And I wish them the best of luck to face the challenges that lie ahead of them.
  102. Re: Reviews[ Go to top ]

    I have a theory, Spring the #1 way of scaring people away from Java.


    Good. I wouldn't want to team up with that particular kind of people you're refering to anyway.

    And I wish them the best of luck to face the challenges that lie ahead of them.
    They are the people that go to Ruby. Hahahahaha In every Java-bashing Spring is cited, does it ring bells to you? Spring is held as a complex solution to a non-problem. Besides, moving code from Java to XML is an utter nonsense. You aren't eliminating dependencies, you are just hiding them. If a Spring developer were to clean a house, it would just sweep the dust to below the carpet and call it "clean".
  103. Re: Reviews[ Go to top ]

    I have a theory, Spring the #1 way of scaring people away from Java.


    Good. I wouldn't want to team up with that particular kind of people you're refering to anyway.

    And I wish them the best of luck to face the challenges that lie ahead of them.


    They are the people that go to Ruby. Hahahahaha In every Java-bashing Spring is cited
    They are a number of other things that are mentioned in Java-bashings: the J2EE environment and even java itself. So according to these people, we should stop programming in java altogether. I'm sure that Ruby is a great language, and I encourage anybody who finds himself lost in the Java world to move on to something simpler and easier for him to handle.
  104. Re: Reviews[ Go to top ]

    Why creating tons of XML is a good thing? Why taking things from Java code to XML is a good thing? Why creating such overhead is a good thing?

    I have a theory, Spring the #1 way of scaring people away from Java.


    It's been repeated hundreds of times, but if you hate XML so much, you can always write simple Java code instead.
    I have never understood the basis for the common dislike of XML, but, as you say, if it is an issue you can, as you say, use Java for configuration. If that is too static, you can use Groovy, or BeanShell, or JRuby, or other languages. In this time when so many frameworks have 'attitude', one of the best things about Spring that it doesn't. It it gives freedom to use alternatives, even alternatives to the way Spring does things (such as in place of Spring MVC). I find this an attractive and mature approach. I would like to add my congratulations to the Spring team. Spring is now an essential part of any Java project I work on, no matter what the type or scale.
  105. Reviews, I am new to Java...[ Go to top ]

    I would like to answer this gentleman who pretends that Spring is scaring off peoples from Java. I am new to Java and use it only since few months. However, I have over 20 years experience in software development using Assembler, C, C++ and Delphi for the last 10 years. I worked as a consultant on numerous projects with large companies for which OO design, standardization and simplification of development practices were important objectives. These requirements lead me to develop many in-house frameworks to achieve these goals. Delphi being a language that is definitively not in expansion, I decided to invest time in learning a new language. I investigated C#/.NET and Java/J2EE. In my Java survey, the first thing that struck me was the sheer amount of "Jacronyms" standing for all kinds of APIs and standards available. As EJB was the "official" way of doing J2EE, I started by reading about it and did little experimentation; believe me, THAT scared me off. Luckilly, I came across lighter approaches of using J2EE and read "J2EE without EJB". This book helped me get a better global picture on what exactly was J2EE and EJB (and some of these Jacronyms). From there I started looking at Spring and other frameworks, investing some time to read and understand the documentation and little bucks to buy few books. I realized pretty soon that Spring was the illusive framework I was chasing in the many in-house projects I worked on. Actually, Spring and ORM tools in general are one of the many reasons that motivated me to make Java the language in which I invest my learning efforts at this time (note: this is not to criticize C#). Spring is the "kind of thing" I can relate very well with as it solves problems encountered in any major project for which responsible developper wants to ensure good OO design, clean code, testability, evolution and perennity no matter the programming language. But to realize that, one has to a) understand and acknowledge these problems and b) put a little effort in widening the beam of it's knowledge that teneously lightens the dark universe of it's ignorance. Jacques Ledoux PS: I almost forgotten to thankfully congratulate the Spring team for their achievement.
  106. As EJB was the "official" way of doing J2EE, I started by reading about it and did little experimentation; believe me, THAT scared me off.
    Then you aren't so "new", because there's a long time EJB isn't the "official" way of doing anything despite of being included in Java EE. It's regarded as complex by the majority of Java developers, and something you should use only if you know what you are doing.
    From there I started looking at Spring and other frameworks, investing some time to read and understand the documentation and little bucks to buy few books.

    I realized pretty soon that Spring was the illusive framework I was chasing in the many in-house projects I worked on.
    Why?
    Spring is the "kind of thing" I can relate very well with as it solves problems encountered in any major project for which responsible developper wants to ensure good OO design, clean code, testability, evolution and perennity no matter the programming language.
    What problems could Spring possibly solve that aren't addressed by OO?? Are you saying that's impossible to build "good OO design", clean code, testable code, easy to evolve and maintain with Java only? So, before Spring Java was nothing? And after Spring all those things are possible?
    But to realize that, one has to a) understand and acknowledge these problems and b) put a little effort in widening the beam of it's knowledge that teneously lightens the dark universe of it's ignorance.
    I am not sure what kind of inadequacy could cause people to so often try to portray themselves as "superior" to others. It has happened a few times in this page and the only thing we can conclude by that is they are trying to look something they are not. No intellectualy honest person could argue that Spring is more than OO, or replaces it. Spring is just an abstraction built with OO, with questionable goals and questionable design choices. DI is a flawed concept, because it's impossible to eliminate dependencies. Will you deny that XML must be written for the Java code you won't write and the application will be dependent on it?
  107. Then you aren't so "new", because there's a long time EJB isn't the "official" way of >doing anything despite of being included in Java EE. It's regarded as complex by the majority of Java developers, and something you should use only if you know what you are doing.
    It may not be obvious to you folks that swim in the Java environment for some period of time to realize that the whole environment is quite intimidating. The language itself is like any other OO language with it's own particularities but nothing specifically complicated. On the other hand, the Java environment (all those technologies that are designated as Jxxx) took me few weeks of research and readings just to build that puzzle and be comfortable in reading texts with references to them. When you start learning about sometning new, one tend to look at things in the order they are presented to you. Looking at books and Sun sites, EJB is the way to go with J2EE using application servers, etc. It takes a little digging to find out that there are other ways of doing it. This was the meaning of the double quoted "official".
    Why?
    To answer this question, I have to quickly draw a picture of where I come from. I was called as consultant on many projects where my mandate was to develop ways to bring some level of standardization in the coding of teams of programmers. Bare in mind that these projects were using Delphi which is a full OO language producing native code with a "VB like" IDE. This IDE, unfortunately, promoted very bad habits among coders that tends to use this facility to embed all sorts of code in event handlers. At worst, the result is that, we find code in the same method that address access security, transaction management, database access, business concerns, etc. No to say that each programmer had his own style of doing this and that his style might change from day to day depending on how he/she felt that morning. At best, this code is moved into one or two classes mainly to support parallel development. So my job was a) to clean up this mess primarily in order to ensure project's independance over individuals and b) improve the code quality as, you probably have guessed, was not always ready for prime time entertainment. My approach was then to a) improve knowledge and usage of sound OO practices in coding with emphasis on separation of concerns and b) provide a standardized access to what I called "horizontal functionnalities" ("crosscutting concerns" in AOP parlance). Of course, I could not use AOP as Delphi produces native code and does not have a very powerfull reflection and dynamic code generation capability (the greatest difference between native and runtimed code). From there, you can figure it out by yourself: create classes to handle these concerns, factories that returns singletons, etc. This cleaned up the code and allowed coders to still be creative in the business aspects (in the meantime, they learned OO and I had to refreain their enthousiasm many times) while producing programs that could be more easily maintained by anybody with a little knowledge of the framework. The remaining problem was testability. To be able to use these common functionnality classes, most of them had to be instanciated by their clients or be accessible globally. This is a major hurdle for unit testing as we simply cannot test a single class by itself without it's dependencies. All of the tentative made to come up with a simple and applicable solution were flacky at best and testing was almost a nightmare. This did not help me promote that aspect of coding. OK back to Spring: having a service class being instanciated by it's client means that you cannot test that client class alone as it creates the other class in it's normal operation. DI injects that service class into the client class without the client class having any knowledge of where it comes from. That does not mean the client class is not dependent on the service class, it simply means that the client class does not have the responsability to instanciate the service class. During unit testing, we can then easily replace the service class instanciation with a mock object and unit test the client class totally independently of the service class. AOP is the other gem as we could have removed all the non-buziness concerns code from the buziness classes and declaratively implement transaction or access security without any specific class instanciation or calls to global instances in the business code. I would have killed (so to speak...;-) to be able to do that in these projects. But for that, you need reflection and dynamic code generation (or whatever it is Jcalled) which were not available in Delphi. This is what I meant by "illusive...".
    What problems could Spring possibly solve that aren't addressed by OO??
    Let's separate Spring from DI and AOP ie let's talk about specification first. You see DI, AOP and OO as being conflicting and this is where you "miss the bus" (free translation from a french proverb;-). OO is like any other thing: too much is like not enough. OO is great to address specific concern one at the time be it buziness or systemic. In the purest OO design reusability and testability is obtainable by limiting as much as possible the knowledge required by one class to be able to use another class (or interface): this is dependency. Dependency is about knowledge of the other class not it's instanciation or how an instance is obtained. The instanciation mechanic requires more knowledge of the target class than it is required for it's simple utilization. Creation parameters, default values and even the correct implementation of an interface are all responsabilities of the factory process. Remove that from the client class and you just removed lots of knowledge about the service class. Only the usage knowledge is then required to access the services. This goal is easier to implement with DI and AOP than without. They allow you to freely address each problem with almost no pre-requisite or external concerns knowing that you can tie everything together declaratively. Again, DI does not eliminate dependency, it simply frees you from the instanciation nightmare and provides the flexibility required for code reuse and testability. As for AOP, it does not replace OO: simply put, it let's you transparently intercept calls in order to address a crosscutting concern which can in turn be itself implemented in a "magnificient OO class design". Spring is certainly not the only way to do these things, To my opinion, Spring is the best way I have found so far to do them. If I ever find something better someday, I will certainly start using it instead as, I am sure, most of the people that use Spring now.
    I am not sure what kind of inadequacy could cause people to so often try to portray themselves as "superior" to others. It has happened a few times in this page and the only thing we can conclude by that is they are trying to look something they are not.
    I don't know about you but I think about myself as being more ignorant than knowledgeable in regards with the sheer amount of knowledge available in the universe. If we circumvent that to a subject of interest like "programming" or "application design" or the like, I think at myself as being less ignorant but still, I have lots of thing to learn. I do not pretend that anyone here has the universal truth with or without Spring and I hopefully think that nobody pretends it. It only seems reasonable to me that intelligent peoples wish to "enlarge the beam of their knowledge". However, when somebody makes definitive judgements like "this IS the main reason that scares people from ..." and that my experience is radically opposite, then I react. Unfortunately, the reasons that are mostly invoked for Spring bashing are, most of the time due to a very poor knowledge of the beast. I can understand peoples that want to stick with their methods as they are proud of their achievements. I, myself, was and still am very proud of what I have accomplished in Delphi. When I looked at Spring and found answers to these problems I fought with and recognize that it is a great solution so I adopted it. Nobody is bound to come to the same conclusion and anybody can use another approach be it personnal or publicly available. What I have problems with is the "bashing instead of learning" attitude. One can criticize if he knows but anybody is free to learn or not. Sorry for that long post. Also, bare in mind that I might have done some "carabistouilles" in my explanations of AOP, DI and Spring as I wrote things the way I see them. Any correctives are welcomed. Jacques Ledoux
  108. Then you aren't so "new", because there's a long time EJB isn't the "official" way of >doing anything despite of being included in Java EE.

    It's regarded as complex by the majority of Java developers, and something you should use only if you know what you are doing.

    It may not be obvious to you folks that swim in the Java environment for some period of time to realize that the whole environment is quite intimidating. The language itself is like any other OO language with it's own particularities but nothing specifically complicated. On the other hand, the Java environment (all those technologies that are designated as Jxxx) took me few weeks of research and readings just to build that puzzle and be comfortable in reading texts with references to them.

    When you start learning about sometning new, one tend to look at things in the order they are presented to you. Looking at books and Sun sites, EJB is the way to go with J2EE using application servers, etc. It takes a little digging to find out that there are other ways of doing it. This was the meaning of the double quoted "official".
    Why?

    To answer this question, I have to quickly draw a picture of where I come from.

    I was called as consultant on many projects where my mandate was to develop ways to bring some level of standardization in the coding of teams of programmers. Bare in mind that these projects were using Delphi which is a full OO language producing native code with a "VB like" IDE. This IDE, unfortunately, promoted very bad habits among coders that tends to use this facility to embed all sorts of code in event handlers.

    At worst, the result is that, we find code in the same method that address access security, transaction management, database access, business concerns, etc. No to say that each programmer had his own style of doing this and that his style might change from day to day depending on how he/she felt that morning. At best, this code is moved into one or two classes mainly to support parallel development.

    So my job was a) to clean up this mess primarily in order to ensure project's independance over individuals and b) improve the code quality as, you probably have guessed, was not always ready for prime time entertainment.

    My approach was then to a) improve knowledge and usage of sound OO practices in coding with emphasis on separation of concerns and b) provide a standardized access to what I called "horizontal functionnalities" ("crosscutting concerns" in AOP parlance).

    Of course, I could not use AOP as Delphi produces native code and does not have a very powerfull reflection and dynamic code generation capability (the greatest difference between native and runtimed code). From there, you can figure it out by yourself: create classes to handle these concerns, factories that returns singletons, etc.

    This cleaned up the code and allowed coders to still be creative in the business aspects (in the meantime, they learned OO and I had to refreain their enthousiasm many times) while producing programs that could be more easily maintained by anybody with a little knowledge of the framework. The remaining problem was testability.

    To be able to use these common functionnality classes, most of them had to be instanciated by their clients or be accessible globally. This is a major hurdle for unit testing as we simply cannot test a single class by itself without it's dependencies. All of the tentative made to come up with a simple and applicable solution were flacky at best and testing was almost a nightmare. This did not help me promote that aspect of coding.

    OK back to Spring: having a service class being instanciated by it's client means that you cannot test that client class alone as it creates the other class in it's normal operation. DI injects that service class into the client class without the client class having any knowledge of where it comes from. That does not mean the client class is not dependent on the service class, it simply means that the client class does not have the responsability to instanciate the service class. During unit testing, we can then easily replace the service class instanciation with a mock object and unit test the client class totally independently of the service class.

    AOP is the other gem as we could have removed all the non-buziness concerns code from the buziness classes and declaratively implement transaction or access security without any specific class instanciation or calls to global instances in the business code.

    I would have killed (so to speak...;-) to be able to do that in these projects. But for that, you need reflection and dynamic code generation (or whatever it is Jcalled) which were not available in Delphi.

    This is what I meant by "illusive...".
    What problems could Spring possibly solve that aren't addressed by OO??

    Let's separate Spring from DI and AOP ie let's talk about specification first.

    You see DI, AOP and OO as being conflicting and this is where you "miss the bus" (free translation from a french proverb;-). OO is like any other thing: too much is like not enough. OO is great to address specific concern one at the time be it buziness or systemic. In the purest OO design reusability and testability is obtainable by limiting as much as possible the knowledge required by one class to be able to use another class (or interface): this is dependency.

    Dependency is about knowledge of the other class not it's instanciation or how an instance is obtained. The instanciation mechanic requires more knowledge of the target class than it is required for it's simple utilization. Creation parameters, default values and even the correct implementation of an interface are all responsabilities of the factory process. Remove that from the client class and you just removed lots of knowledge about the service class. Only the usage knowledge is then required to access the services.

    This goal is easier to implement with DI and AOP than without. They allow you to freely address each problem with almost no pre-requisite or external concerns knowing that you can tie everything together declaratively. Again, DI does not eliminate dependency, it simply frees you from the instanciation nightmare and provides the flexibility required for code reuse and testability. As for AOP, it does not replace OO: simply put, it let's you transparently intercept calls in order to address a crosscutting concern which can in turn be itself implemented in a "magnificient OO class design".

    Spring is certainly not the only way to do these things, To my opinion, Spring is the best way I have found so far to do them. If I ever find something better someday, I will certainly start using it instead as, I am sure, most of the people that use Spring now.

    I am not sure what kind of inadequacy could cause people to so often try to portray themselves as "superior" to others. It has happened a few times in this page and the only thing we can conclude by that is they are trying to look something they are not.

    I don't know about you but I think about myself as being more ignorant than knowledgeable in regards with the sheer amount of knowledge available in the universe. If we circumvent that to a subject of interest like "programming" or "application design" or the like, I think at myself as being less ignorant but still, I have lots of thing to learn. I do not pretend that anyone here has the universal truth with or without Spring and I hopefully think that nobody pretends it. It only seems reasonable to me that intelligent peoples wish to "enlarge the beam of their knowledge".

    However, when somebody makes definitive judgements like "this IS the main reason that scares people from ..." and that my experience is radically opposite, then I react. Unfortunately, the reasons that are mostly invoked for Spring bashing are, most of the time due to a very poor knowledge of the beast. I can understand peoples that want to stick with their methods as they are proud of their achievements. I, myself, was and still am very proud of what I have accomplished in Delphi.

    When I looked at Spring and found answers to these problems I fought with and recognize that it is a great solution so I adopted it. Nobody is bound to come to the same conclusion and anybody can use another approach be it personnal or publicly available. What I have problems with is the "bashing instead of learning" attitude. One can criticize if he knows but anybody is free to learn or not.


    Sorry for that long post. Also, bare in mind that I might have done some "carabistouilles" in my explanations of AOP, DI and Spring as I wrote things the way I see them. Any correctives are welcomed.

    Jacques Ledoux
    Very good post Jacques. It's nice to hear someone having a different background.
  109. ... To be able to use these common functionnality classes, most of them had to be instanciated by their clients or be accessible globally. This is a major hurdle for unit testing as we simply cannot test a single class by itself without it's dependencies. All of the tentative made to come up with a simple and applicable solution were flacky at best and testing was almost a nightmare. This did not help me promote that aspect of coding.

    OK back to Spring: having a service class being instanciated by it's client means that you cannot test that client class alone as it creates the other class in it's normal operation. DI injects that service class into the client class without the client class having any knowledge of where it comes from. That does not mean the client class is not dependent on the service class, it simply means that the client class does not have the responsability to instanciate the service class. During unit testing, we can then easily replace the service class instanciation with a mock object and unit test the client class totally independently of the service class.
    I ignored the initial part of your text because that's a "standard rant", and it has nothing to do with Spring or not-Spring. That's what you will most likely find in Delphi or VB projects. The test factor is problably the only place DI would help, but even without it it's possible to build good test cases. And with the complexity of the framework added to the equation, if you use Spring solely for "ease of testing" then it doesn't pay off. There are easier ways of doing it. The learning curve and the complexity added (dependency on Spring configuration files, maintainability and readability decreased, etc) would be far greater than the benefits of it.
    AOP is the other gem as we could have removed all the non-buziness concerns code from the buziness classes and declaratively implement transaction or access security without any specific class instanciation or calls to global instances in the business code.

    I would have killed (so to speak...;-) to be able to do that in these projects. But for that, you need reflection and dynamic code generation (or whatever it is Jcalled) which were not available in Delphi.

    This is what I meant by "illusive...".
    Whenever I consider a new technology I weight the bad and the good, and if the final sum is positive then I consider using it. AOP introduces many problems as well it solves. The readability is destroyed, because the code that will run is not included in that region of the source code, similar to a goto statement. Besides, AOP it's not the only way of shielding the developers from "programming problems". Take a look at Java EE, doesn't it solve many "programming problems" we shouldn't care about? That is done without AOP and without the associated problems of it. It's possible through great pains even to program OO in plain C, but what I mean it's not that. It's that the cost/benefit (complexity vs. solution) of AOP isn't interesting, at least for now. I have the impression the AOP hype came to fill a void people felt after OOP was established in the mainstream, the need for "the next big thing".
    You see DI, AOP and OO as being conflicting and this is where you "miss the bus" (free translation from a french proverb;-).
    No, I never said it was conflicting, just that DI is flawed and that AOP is unnecessary.
    OO is like any other thing: too much is like not enough. ... Again, DI does not eliminate dependency, it simply frees you from the instanciation nightmare and provides the flexibility required for code reuse and testability.
    Ok, I cut the part about explaining DI, but I think you didn't understand what I said. I said it's better to have "flexibility, reuse and everything else" through well developed abstractions in OO than through Spring. I never said "flexibility, reuse and everything else" is bad. I only said Spring amounts for a huge complexity, not only the framework itself, but how the developers will work on it and how projects will be structured to make use of it. For example, the project will depend on Spring. Won't it? What if you remove the configuration file, won't it stop working? Won't you need to rewrite that piece of code to work without Spring? So, you see, the "invasive" factor is there even if implementing interfaces from Spring aren't required for using it. One of the benefits of Java EE is the component model, Servlets and other stuff. Why? Because they define a functionality pretty well and we know how to work with all cases of it by knowing it. What would happen if everyone could create its own POJO-like components and "wire" this up the way they felt that morning? Wouldn't it be a mess? The point here is: it's preferrable to achieve flexibility, reuse, testability and quality through well defined abstractions and use them in a well defined component model, than with the Spring framework (DI and AOP). Annotations are one thing that could benefit greatly our ability to build more flexible solutions.
    ... However, when somebody makes definitive judgements like "this IS the main reason that scares people from ..." and that my experience is radically opposite, then I react.
    React by offending other people? It's better to just say that you don't agree and why, but you preferred to use the "I am better than you" line instead. I don't really care about it at all, but the same way you react by "definitive judgements" like that, I feel the need to react to such pretentious people.
    Unfortunately, the reasons that are mostly invoked for Spring bashing are, most of the time due to a very poor knowledge of the beast. I can understand peoples that want to stick with their methods as they are proud of their achievements. I, myself, was and still am very proud of what I have accomplished in Delphi.
    No, the bashing lies in the very concepts in which Spring was built upon. Otherwise it would be just a matter "which implementation of this concept is better" and we aren't talking about implementations.
    ... What I have problems with is the "bashing instead of learning" attitude.
    Ad hominem. You have absolutely no idea of anyone in this forum and their experiences, so how did you get to this conclusion? So, only hardcore fans opinions are valid?
  110. Most of your replies are judgement calls based on your experience and knowledge. It happens that I disagree with most if not all of them including their argumentation. But hey, you have your reasons... As for the remark you make about me offending other people, I suggest that you read your previous posts to realize (if you can) that I certainly have no lessons to take from you on that matter. My suggestion to you here is before keyboarding in forums like this one, just assume that other people's sensibility trigger is as delicate as your's. Finally, you have no idea of the knowledge I have about the experience and opinions of other persons on this forum. On the other hand, your posts are more than enough to give me a precise idea about yours. From there, I'll be the only judge of whom I will take advice from. Amen, Jacques Ledoux
  111. Re: Reviews, I am new to Java...[ Go to top ]

    Most of your replies are judgement calls based on your experience and knowledge. It happens that I disagree with most if not all of them including their argumentation. But hey, you have your reasons...

    As for the remark you make about me offending other people, I suggest that you read your previous posts to realize (if you can) that I certainly have no lessons to take from you on that matter. My suggestion to you here is before keyboarding in forums like this one, just assume that other people's sensibility trigger is as delicate as your's.

    Finally, you have no idea of the knowledge I have about the experience and opinions of other persons on this forum. On the other hand, your posts are more than enough to give me a precise idea about yours. From there, I'll be the only judge of whom I will take advice from.

    Amen,

    Jacques Ledoux
    Well said, Jacques. Like you, I would love nothing more than a good discourse about Spring. It is rare treat to get the likes of the Spring creators on these forums and is a shame that this thread has degenerated so. I was impressed by your post because it mirros my own experience. What I've noticed is that the people who use Spring tend to use it for the same reasons. IMO, Spring success can be directly attributed to solving a fundamental problem that, as you've demostrated, cuts across languages and even countries. Like you, I've found that AOP has significantly increased our maintainability despite protestations to the contrary. The AOP detractors today remind me quite a bit of the OOP detractors of the late 80's/early 90's. Back then it was OOP didn't solve any problems that precedural coding couldn't solve. That OOP made the code harder to read(inheritence? polymorphism anyone). That it was harder to learn...heck it is almost an exact mapping of the arguements we've read here. It will be interesting to see what the future AOP people say about the new paradigm in the teens. Remember people, "Spring forward, or fall behind!" :-)
  112. The AOP detractors today remind me quite a bit of the OOP detractors of the late 80's/early 90's. Back then it was OOP didn't solve any problems that precedural coding couldn't solve. That OOP made the code harder to read(inheritence? polymorphism anyone). That it was harder to learn...heck it is almost an exact mapping of the arguements we've read here. It will be interesting to see what the future AOP people say about the new paradigm in the teens.

    Remember people, "Spring forward, or fall behind!" :-)
    Is this "patterns of time" reason enough to make you an AOP believer? It almost reminds me the Ruby fanatics that use the same logic to say that "Java is dead", because "every 10 years something new takes over" (sic). So where's the connection of cause and effect between what people said of OOP 20 years ago and what other people say about AOP now? I think the biggest obstacle to OOP adoption were the maturity of the tools. Today we have plenty of tools to choose from, not to mention the internet, this alone makes the scenario much easier for AOP spread in a much faster rate, but why doesn't it do it? Why don't we have AOP in the standard Java platform? If 99% of all developers were using it, JCP would have no option or people would start using other stuff. I really would like to see some evidence on this "more maintainable" taken out of nowhere. About being "harder to learn" I disagree, it's quite easy, but the point is not that. Any HelloWorld or a few lines of example code in a website looks excellent, in the real world it's a different story.
  113. Re: Reviews, I am new to Java...[ Go to top ]

    I think the biggest obstacle to OOP adoption were the maturity of the tools. Today we have plenty of tools to choose from, not to mention the internet, this alone makes the scenario much easier for AOP spread in a much faster rate, but why doesn't it do it?
    OOP always had good tools, for example, one of the languages that helped pioneered modern OOP - Smalltalk - has had rich IDE/tool features for designing, browsing and debugging OOP since the 70s. Mainstream languages gained OOP and tools in the 80s. It seems to me that the reason for the slow adoption of OOP is just the same as the reason for the current slow adoption of AOP - the IT industry has always been highly conservative. Good OOP tools have been around in a popular languages for decades, but OOP has only become mainstream relatively recently.
  114. Re: Reviews, I am new to Java...[ Go to top ]

    OOP always had good tools, for example, one of the languages that helped pioneered modern OOP - Smalltalk - has had rich IDE/tool features for designing, browsing and debugging OOP since the 70s. Mainstream languages gained OOP and tools in the 80s. It seems to me that the reason for the slow adoption of OOP is just the same as the reason for the current slow adoption of AOP - the IT industry has always been highly conservative. Good OOP tools have been around in a popular languages for decades, but OOP has only become mainstream relatively recently.
    Also, the presence of good tools don't make good OO programmers. Delphi has a wonderfull IDE but there are still lot's of programmer out there that use it as a "component dropping / event handler stuffing" tool. ModelMaker is the tool that really helps with classes hierarchy and OO design and implementation: very few know about it. The problem here are not the IDE's themselves but the knowledge and disciplin of coders: in these case, these IDEs do wonders. It is true that IT industry has always been conservative: the sheer number of legacy systems are not always easy or worthwhile to port. This is a serious reason why a paradigm like OO or AOP takes some time to make their way. At the end though, their intrinsic value prevail and they end up being widely used in new projects. Jacques
  115. Re: Reviews, I am new to Java...[ Go to top ]

    ... the IT industry has always been highly conservative. Good OOP tools have been around in a popular languages for decades, but OOP has only become mainstream relatively recently.
    Nowadays we don't have any "islands", everyone uses the internet and get information through it, so it's difficult not to know about things and not to be influenced one way or another. Getting tools it's just a matter of downloading a "free as in beer" piece of software that pretty well. It's a very different scenario from 20 years ago when things weren't so easy.
  116. The AOP detractors today remind me quite a bit of the OOP detractors of the late 80's/early 90's. Back then it was OOP didn't solve any problems that precedural coding couldn't solve. That OOP made the code harder to read(inheritence? polymorphism anyone). That it was harder to learn...heck it is almost an exact mapping of the arguements we've read here. It will be interesting to see what the future AOP people say about the new paradigm in the teens.

    Remember people, "Spring forward, or fall behind!" :-)


    Is this "patterns of time" reason enough to make you an AOP believer? It almost reminds me the Ruby fanatics that use the same logic to say that "Java is dead", because "every 10 years something new takes over" (sic).

    So where's the connection of cause and effect between what people said of OOP 20 years ago and what other people say about AOP now?

    I think the biggest obstacle to OOP adoption were the maturity of the tools. Today we have plenty of tools to choose from, not to mention the internet, this alone makes the scenario much easier for AOP spread in a much faster rate, but why doesn't it do it? Why don't we have AOP in the standard Java platform? If 99% of all developers were using it, JCP would have no option or people would start using other stuff.

    I really would like to see some evidence on this "more maintainable" taken out of nowhere. About being "harder to learn" I disagree, it's quite easy, but the point is not that. Any HelloWorld or a few lines of example code in a website looks excellent, in the real world it's a different story.
    No, my direct experience using both OOP and AOP tells me that AOP complements OOP very well. Perhaps if you used it, you would have a more accurate impression. As for that connection, you, Thiago, just remind me of the precedural programmers of yesterday in your vehemence that AOP is so "unnecessary". Everything you say was said about OOP. And about high level languages before that. Eventually they came around or found a good niche in which to occupy themselves without disturbing the world around them *too* much. Further, I don't recall anyone saying "Helloworld". You had several people, myself included, give concrete examples of how and why we use AOP. You've convienently ignored each one. In the real world, AOP has provided benefits that are well real. I don't buy any argument you make about the adoption rate of AOP, about what it is or how fast it is occuring. You've demostrated that you have both an axe to grind and that you don't even bother reading enough about the material to have a minimal level of competence on the subject matter, so to be frank, who cares what you think? I'm not quite sure that "more maintainable take out of nowhere" means, so I cannot comment on that. I can comment on how our people from Juniors to Seniors have been able to work within our framework with little effort, so I choose to use that as a metric as opposed to the experiences of someone with no experience on the subject matter.
  117. As for that connection, you, Thiago, just remind me of the precedural programmers of yesterday in your vehemence that AOP is so "unnecessary". Everything you say was said about OOP. And about high level languages before that. Eventually they came around or found a good niche in which to occupy themselves without disturbing the world around them *too* much.
    I could map some arguments of Java developers regarding Ruby and other dynamic languages to C++ developers when Java was "the next big thing". So what? This accounts for no fact as far as I know. I would really like to see how things are going to be in 100 years. Will every 10 years or so Something-Oriented-Programming pop up as the next level in abstractions and people use the same arguments you are using now? Will every 2 years or so a new hype on the internet still cause a lot of debate?
  118. Will every 10 years or so Something-Oriented-Programming pop up as the next level in abstractions and people use the same arguments you are using now?
    I hope so. Unless you believe that OOP is the last word in programming and we don't need any further innovation, all problems have been solved and development of programming paradigms is at an end. Which is self-evidently not the case. OOP is good, but doesn't solve all problems. Business requirements become continually more complex--for example, with the impact of the web on more and more parts of the business, and ever-increasing sophistication in financial service and other products. New techniques need to be developed to manage that complexity or we are all in deep trouble. There is a natural move toward higher level of abstractions and additional ways of conceptualizing applications.
    Will every 2 years or so a new hype on the internet still cause a lot of debate?
    Without discussion and innovation, there cannot be progress. "Hype" is not necessarily helpful, but occasional hype is a lesser evil than failing to push the envelope...
  119. Thanks for the feedback[ Go to top ]

    Hi Rod, As one of the skeptics, I appreciate you taking the time to not only answer our concerns but to do it in a professional manner. I can see it can be pretty harsh out here. But, on the other hand, I guess it's a good thing to have so many people who are passionate about their craft. In the end, we're all just trying to make better code. Paul
  120. Re: Thanks for the feedback[ Go to top ]

    As one of the skeptics, I appreciate you taking the time to not only answer our concerns but to do it in a professional manner.
    Thanks, Paul--I appreciate this and am glad my posts were worth reading. Rgds Rod
  121. I hope so. Unless you believe that OOP is the last word in programming and we don't need any further innovation....
    I think you are purposefully misinterpreting what I said. I didn't say innovation is bad and OOP is all we need, I said "hype" is bad and following a new trend every two years is bad. This is like building castles of sand for the tide to take them down. Look at other areas such as Mathematics and Physics, they have built solid foundations based on a well defined criteria and rigor when evalutating new theories. Even engineering have standardized many things. Now look at IT, it's in a constant state of "who-said-what", "opinionated software", unproved claims and such. Is this good? Is this innovation? I don't think so.
    Without discussion and innovation, there cannot be progress. "Hype" is not necessarily helpful, but occasional hype is a lesser evil than failing to push the envelope...
    I believe any "hype" is evil, because it makes people not to evaluated something for what it is, but instead it creates a whole religion around it.
  122. I think you are purposefully misinterpreting what I said. I didn't say innovation is bad and OOP is all we need, I said "hype" is bad and following a new trend every two years is bad.
    Re-read my post. You will find that I quoted exactly what you said prior to the comments you're replying to here. What you said was "Will every 10 years or so Something-Oriented-Programming pop up as the next level in abstractions and people use the same arguments you are using now?".
    Now look at IT, it's in a constant state of "who-said-what", "opinionated software", unproved claims and such. Is this good? Is this innovation? I don't think so.
    Most of the people you have been arguing with in this thread have either advanced real arguments or--in most cases--spoken of their practical experience: evidence. You, OTOH have a lot of opinions but do not seem to have practical evidence to hand.
  123. ...what you said prior to the comments you're replying to here. What you said was "Will every 10 years or so Something-Oriented-Programming pop up as the next level in abstractions and people use the same arguments you are using now?".
    Now let's think, why would I say that? Maybe because "change for the sake of change" and "hype for the sake of hype" popping up here and there every 2 years is bad? Maybe because jumping in the latest "fashionable term" is not exactly what we may call "solid foundations"? Coming back to my point, do you really expect this "blogfest" to go on for the next 100 years? I think everything changed too fast because of the internet and PC widespread use, in 30 years I hope this field gets more mature, and people won't feel the same urge to jump to the latest fad for the 27th time, only to learn 2 years later that "that's wrong" and new shiny thing will save your life. Building solid foundations is a complete different matter, and THAT'S what I would call evolution and innovation.
    Most of the people you have been arguing with in this thread have either advanced real arguments or--in most cases--spoken of their practical experience: evidence. You, OTOH have a lot of opinions but do not seem to have practical evidence to hand.
    Anedoctal evidence cannot be relied upon. The perfect example of "evidence" put here was some guy that said "McDonalds is hiring" (search in the page), i.e., only Spring developers know the "one true path" to "clean, robust, scalable code" and anyone else is just wrong.
  124. Re: Reviews, I am new to Java...[ Go to top ]

    The perfect example of "evidence" put here was some guy that said "McDonalds is hiring" (search in the page), i.e., only Spring developers know the "one true path" to "clean, robust, scalable code" and anyone else is just wrong.
    That would be true if your interpretation of my comment was correct. It isn't. It was directed at the posters comment to not be able to "get" anything beyond jdbc and servlets and/or why we don't need anything more. And beyond that, I put a little :) which pretty much meant I was jerking his chain. Anecdotal evidence is via story or hearsay. We've had people say "works for me" not "I heard it works for Fred". While it is not via the scientific method, I doubt that truely could be done via the scientific method.
  125. Re: Reviews, I am new to Java...[ Go to top ]

    Anecdotal evidence is via story or hearsay. We've had people say "works for me" not "I heard it works for Fred". While it is not via the scientific method, I doubt that truely could be done via the scientific method.
    First, I think your comment to the other poster was offensive and a perfect example of the "snob consultant" complex in the Spring community. Spring is to Java what religious extremists are to religion, they do believe they know the only true way and everyone else is wrong, in the first case it means that every non-Spring developer is bad developer, and in the second case it means that everyone not from the religion X is damned to hell for all eternity. Second, the description of "works for me" falls perfectly in a story, and nothing more. Honestly, it's hard to say what's more annoying, Spring zealots or Ruby zealots. You have so much in common!
  126. Re: Reviews, I am new to Java...[ Go to top ]

    Spring success can be directly attributed to solving a fundamental problem that, as you've demostrated, cuts across languages and even countries.
    You are so right and this is exactly where I kicked off with Spring. While reading "J2EE development without EJB", I was amazed by the exact similarities of the motivations for the framework vs the problems I was addressing. Of course, running under a JVM, Java has some possibilities that native code language don't and AOP is certainly one great way of taking advantage of this. Not having these capacities at hand forced me to stick with what I had ie the OO exclusively. Wether using an inheritance or composition approach, the most "carefully crafted component architecture" becomes rapidly jammed packed with those crosscutting concerns and it's maintenance and utilization complexity grows accordingly. In my opinion, the best abstraction is the one I don't have to see but still,I know it's there. That way, when I look at a method addressing a buziness concern, I see code that "talks" about buziness and nothing about transaction, security, logging, etc. Heck, like UML representing domain, I could show the code to domain expert and they would understand what I am doing (I don't do that regularly of course and I mention it here to avoid epidemic reactions and to spare some sensibilities). To me AOP is a litlle bit like driving a car: while you drive, you look up front (I hope) dealing with the traffic on your way to your destination (buziness concern). You don't need to see the pedals, stick shift, the wheels spinning, the gears turning or the piston travelling (all crosscutting concerns). You simply know they are there and doing their job. Yet, if nothing happens when you turn the key or if suddenly, the car start pulling on the right, you (or your favorite debugging expert) will have some idea of what is going wrong and know where to start looking for the "bug". All this comes with the price of code with strict separation of concerns which makes things a little confusing at the beginning. But again, once coders are used to it and disciplined enough to pertinently comment the code, they know exactly where to look when they need to evolve or debug the code. As with the code, coders must be able to change. This is nothing more than deciding on coding style and other project policies. They are harder to apply at the beginning but soon become automatic behavior.
    The AOP detractors today remind me quite a bit of the OOP detractors of the late 80's/early 90's
    This kind of statement somewhat painfully reminds me that I (and probably you too) used to be a young nerd (the key word being "young";-) but that is true. Most of the time the argument is that the program WORKS without it (OO, AOP, Di, etc). Of course it works as we would not expect anything less: you have nothing if the program you write does not work. While some see a "program that works" as a finality, people that spend times to improve their coding structure with or without any acronymed technology are investing in the maintainability and evolution potential of their code. Using abstraction is the first step but using recognized and valuable technologies helps even better by widening the number of people that can work on the code. These are the real problems. The rest is personnal ingenuity, skills and knowledge and, luckily, there is plenty of it out there. Jacques
  127. Most of your replies are judgement calls based on your experience and knowledge. It happens that I disagree with most if not all of them including their argumentation. But hey, you have your reasons...
    So do I. Most of your replies were nothing but opinions based in your knowledge or the lack of it, and I disagree with most of it.
    Finally, you have no idea of the knowledge I have about the experience and opinions of other persons on this forum. On the other hand, your posts are more than enough to give me a precise idea about yours. From there, I'll be the only judge of whom I will take advice from.
    My posts were just questions to "urban legends". All the ones included in this thread or in others. It's only through questioning that some knowledge can be attained, the complain of it is quite ironic coming from someone that claims "to recognize his own ignorance". How do you get knowledge, through divine intervention? Through blindly believing in some stranger's opinions? Or going with the herd?
  128. My posts were just questions to "urban legends". All the ones included in this thread or in others.

    It's only through questioning that some knowledge can be attained, the complain of it is quite ironic coming from someone that claims "to recognize his own ignorance". How do you get knowledge, through divine intervention? Through blindly believing in some stranger's opinions? Or going with the herd?
    No one is complaining about your "questions" (they're more opinions than a questions, IMO), but about your attitude in this thread, offending and being plain agressive to anyone who disagrees with you. Most people just answered your "questions" clearly, explaining factually the hows and whys of Spring, but you kept attacking and annoying them. IMO, you're just mistaking people's satisfaction using a tool with some kind of superior attitude.
  129. ... you're just mistaking people's satisfaction using a tool with some kind of superior attitude.
    I don't think I am, please reread the posts especially from a guy called McCoy or something like that, "... for me it's just Wednesday".
  130. ... you're just mistaking people's satisfaction using a tool with some kind of superior attitude.


    I don't think I am, please reread the posts especially from a guy called McCoy or something like that, "... for me it's just Wednesday".
    I invite anyone to reread it. Someone said that they didn't need certain functions in Spring, that they were concerned about "abstraction leak". I explained how I *need* those abstractions. How I had to port a project in one dev cycle from Oracle 9ias to Jrun to Tomcat and Spring handled this with a single configuration file change. We support Tomcat to Websphere and we have projects that are currently running under several app servers, Tomcat, across Windows and Unix, and even had a SQL Server port rear its head. That is my reality. That is my Wednesday. Those abilites you disregard so casually as "bloat" or "leak" are crucial to me performing my job. What is unnecessary for you may be necessary for others and Spring has to meet all of those needs.
  131. Re: Reviews, I am new to Java...[ Go to top ]

    David, Someone in this thread is in desperate need of attention. His only goal is to prevail at any price. I think a lot of people tried to honestly establish intelligent and informative exchange with him but all these efforts were turned down aggressively. Any honest person that don't agree with using these technologies would have leaved this thread after having been answered half the times by half the people. So what's the point is he trying to make? To me, his hanging around seems like a sign that he has nowhere else to hang. At this time, any energy spent into this kind of deaf dialog is energy wasted. And according to your Wednesday agenda, you need all the energy you can spare ;-)) Jacques
  132. Re: Reviews, I am new to Java...[ Go to top ]

    David,

    energy you can spare ;-))

    Jacques
    Touche'! See you next thread...
  133. ...And with the complexity of the framework added to the equation, if you use Spring solely for "ease of testing" then it doesn't pay off. There are easier ways of doing it.
    Could you provide a concrete example of a OO abstration which makes it much easier than using Spring? You know, anyone can say "there are easier ways of doing it", but I'd like to see some actual code proving it. Pardon my limited knowledge of OO, but I really want to be enlighted by an actual example code if you could provide me one, to compare the "Spring way" and the "OO way". Maybe then people will understand your position better.
  134. Re: Reviews[ Go to top ]

    I have a theory, Spring the #1 way of scaring people away from Java. They don't do OO, they do "Spring oriented programming" and people start thinking that in order for anything to be done in Java you need a "Spring-esque configuration file hell".
    This comment of Thiago is pertinent. I have asked myself this question many times, and I must answer theses kind of questions all the time when I show Spring to my co-worker. On a first glance, it can look odds to put so much "code" inside XML files, and therefore limiting the IDE/Compilation direct and classic validation. It seems like a contradiction to build software outside the java code. The way I am answering this question (to myself) is that the software you are java-building consist of programming independent components (Spring beans). The beans are business and functional centric. This is where Java is useful. On the other hand, Spring Xml Configuration can be understood as an integration framework of business beans. The integration framework addresses primary the non-functional/integration issues. I think that this separation of concern is a great and major contribution to java programming. I think it is almost greater than the MVC paradigm. The integration/configuration part is (Spring configuration), in a way, outside your component based software. Therefore, it is easier to understand software, or a "business domain model" in a Spring way. About scaring people away, I want to argue that Java was not intended for script-kids. Regards, Etienne Laverdière Paris
  135. About the component model[ Go to top ]

    Etienne
    The way I am answering this question (to myself) is that the software you are java-building consist of programming independent components (Spring beans). The beans are business and functional centric. This is where Java is useful. On the other hand, Spring Xml Configuration can be understood as an integration framework of business beans. The integration framework addresses primary the non-functional/integration issues.
    This is the intention of Spring. The aim is not to program in XML, but to use XML configuration to help define a flexible component model that externalizes things that are best defined outside Java, and provide access to a range of value added services, such as declarative transactions, custom aspects, transparent JMX export, numerous extension points, Acegi security etc. Where you don't need to externalize, just use new... And, as other posters have pointed out, Spring's internal metadata is not tied to XML anyway... Rgds Rod
  136. all I want for Christmas...[ Go to top ]

    Is Groovy scripting as a replacement language of Spring XML-based configuration. The Groovy markup feature makes it a natural procedural-capable stand-in for declarative XML. Also a nice outcome, other than being able to mix procedural scripting and declarative programming together, is that Groovy permits strong type declarations (or can just stick with loose typing as well). And Groovy closures could not doubt be handy as well as nice syntax for such things as initializing a map. So all the ills that folks have complained about over the millennium regarding Spring XML-based configuration could be addressed by using Groovy scripting in its place. It would be really sweet if Spring Framework 2.1 offered this out of the box, so to speak.
  137. Re: all I want for Christmas...[ Go to top ]

    Is Groovy scripting as a replacement language of Spring XML-based configuration. The Groovy markup feature makes it a natural procedural-capable stand-in for declarative XML.
    Spring 2.0 allows Spring components to be written in Groovy, JRuby etc.--not Spring to be configured in Groovy. I agree this would be interesting to investigate. Whether it will happen before Christmas, I don't know :-) We are actively prototyping a Java configuration option for Spring, which can be mixed and matched with XML and properties-based configuration. Hopefully we will have a release of this, at least, before Christmas. In the longer term, I would like to see Spring facilitate mixing of configuration from disparate sources. Currently it supports XML and properties based configuration out of the box, with the ability to plug in other forms. Pitchfork also handles annotation-based configuration. I would like to add support for database-backed and Java configuration, allowing sophisticated management of configuration that varies at different rates. Database configuration could also be hooked in with Spring JMX and potentially allow dynamic reconfiguration... All of these things can be built on the Spring core without modifying it, so we're talking about new code rather than changes, but we don't have any firm schedule at this point. Rgds Rod
  138. Re: all I want for Christmas...[ Go to top ]

    We are actively prototyping a Java configuration option for Spring, which can be mixed and matched with XML and properties-based configuration. Hopefully we will have a release of this, at least, before Christmas.
    Groovy has the same advantage as XML text files - it can be tweaked and the changes immediately made use of without going through a compilation and re-jar step (i.e., edit-save-run instead of edit-save-build-re-package-run). Plus it has a number of convenient syntactic advantageous over Java language - especially for declaring the initialization of data structures such as maps and arrays. The Groovy markup feature is kind of the ultimate example of that manner of convenience. Also, as I alluded to in my posting, one can avail strong type checking as well by explicitly declaring the types of things instead of using Groovy's type permissiveness declaration style (yet there will be times when the type permissiveness is also a distinct advantage - Groovy lets one do both mixed together). Currently XML files result in being parsed with an instantiated XML DOM as the outcome. A Groovy script using the markup feature, when executed, will likewise result in an instantiated XML DOM. If Spring Framework configuration can take an XML DOM as an input, then there is a ready and easy integration point for integrating a Groovy scripting approach for Spring configuration.
  139. Re: all I want for Christmas...[ Go to top ]

    Roger
    If Spring Framework configuration can take an XML DOM as an input, then there is a ready and easy integration point for integrating a Groovy scripting approach for Spring configuration.
    Currently the Spring configuration extension point is entirely decoupled from XML: only one or two classes know anything about XML. A BeanDefinitionRegistry can be populated by any type of configuration source, as the core metadata is Java, not XML. However, it might be possible (and probably relatively easy) to refactor the XML-based bean definition reader to start with Groovy. Thanks for the idea! Rgds Rod
  140. Re: all I want for Christmas...[ Go to top ]

    We are actively prototyping a Java configuration option for Spring, which can be mixed and matched with XML and properties-based configuration. Hopefully we will have a release of this, at least, before Christmas.


    Groovy has the same advantage as XML text files - it can be tweaked and the changes immediately made use of without going through a compilation and re-jar step (i.e., edit-save-run instead of edit-save-build-re-package-run). Plus it has a number of convenient syntactic advantageous over Java language - especially for declaring the initialization of data structures such as maps and arrays. The Groovy markup feature is kind of the ultimate example of that manner of convenience. Also, as I alluded to in my posting, one can avail strong type checking as well by explicitly declaring the types of things instead of using Groovy's type permissiveness declaration style (yet there will be times when the type permissiveness is also a distinct advantage - Groovy lets one do both mixed together).

    Currently XML files result in being parsed with an instantiated XML DOM as the outcome. A Groovy script using the markup feature, when executed, will likewise result in an instantiated XML DOM. If Spring Framework configuration can take an XML DOM as an input, then there is a ready and easy integration point for integrating a Groovy scripting approach for Spring configuration.
    Could you post a small example of what configuring bean using java, but resulting in a DOM would look like?
  141. Re: Spring 2.0 goes final[ Go to top ]

    Congratulations Spring Team! Spring 2.0 is looking awesome, looking forward to getting deeper into it.
  142. Re: Spring 2.0 goes final[ Go to top ]

    Congratulation Rod and the rest of the Interface21 team. I see that some of the comments on this thread are questioning the value of Spring. Most of the responses aimed to point the value of Spring for simplifying the application configuration. In our (GigaSpaces) case the reason we looked into spring was completely different – we wanted to find ways to bring the value of our platform scalability and performance to applications seamlessly and in a simple manner. The level of abstraction that spring provides through the Declarative Transactions, DAO support, Remoting, Declarative caching enables us to focus on providing better implementation of our runtime to each of those interfaces without changing the Spring based application. During the experience of working closely with I21 I found how fast they respond to users needs through the Spring Modules projects. The new OSGI support looks very promising and I look forward to integrate that with our platform. Keep on the good work! Nati S. GigaSpaces GigaSpaces-Spring integration
  143. Re: Spring 2.0 goes final[ Go to top ]


    I searched the whole thread using "hibernate" and "toplink". Hibernate appeared 4 times while toplink appeared 1 time (once). Can we say toplink is making some progress? No flame. Just trying to find out market trend. Another interesting off topic. IBM is awarded a huge new development project from a huge government department in Australia. What do they use? EJB2. Yes, EJB2. Including CMP and BMP.
  144. Re: Spring 2.0 goes final[ Go to top ]

    Another interesting off topic. IBM is awarded a huge new development project from a huge government department in Australia. What do they use? EJB2. Yes, EJB2. Including CMP and BMP.
    See here: http://australianit.news.com.au/articles/0,7204,20491812%5E24173%5E%5Enbv%5E24169,00.html
  145. Re: Spring 2.0 goes final[ Go to top ]

    Another interesting off topic. IBM is awarded a huge new development project from a huge government department in Australia. What do they use? EJB2. Yes, EJB2. Including CMP and BMP.

    See here:
    http://australianit.news.com.au/articles/0,7204,20491812%5E24173%5E%5Enbv%5E24169,00.html
    Also here: http://it.seek.com.au/users/apply/index.ascx?Sequence=32&PageNumber=1&JobID=7714320
  146. less frameworks == better[ Go to top ]

    First the 'experts' tell us they have a persistence 'solution' for us (ORM) that is complicated, messy and can't do half the things you can do with vendor specific SQL. Now the 'experts' tell us they have a 'solution' for the persistence 'solution'. We are to use this reflection/injection/xml based abomination to fix all of the problems created in their first 'solution'. I just don't get it. I think the Java folks did wrong when they got away from simple Servlets/JSP and JDBC.
  147. I think the Java folks did wrong when they got away from simple Servlets/JSP and JDBC.
    That would imply the following: 1) All functionality needed in all J2EE applications can be addressed by using solely Servlets/JSP and JDBC. 2) The solution provided by those three technologies is always simpler than with a more advanced/complex one. I think anybody who has worked in complex environments (highly transactional, resource intensive etc...) would probably disagree with 1). As for 2), just compare the JDBC code you have to write in a "simple" appplication vs the one you have to write in Spring: http://www.oracle.com/technology/pub/articles/marx_spring.html
  148. I think the Java folks did wrong when they got away from simple Servlets/JSP and JDBC.


    That would imply the following:

    1) All functionality needed in all J2EE applications can be addressed by using solely Servlets/JSP and JDBC.

    2) The solution provided by those three technologies is always simpler than with a more advanced/complex one.

    I think anybody who has worked in complex environments (highly transactional, resource intensive etc...) would probably disagree with 1).

    As for 2), just compare the JDBC code you have to write in a "simple" appplication vs the one you have to write in Spring:

    http://www.oracle.com/technology/pub/articles/marx_spring.html
    Give me a break. I've alredy written my own JDBC utilities (as have most developers) that require less code than the Spring example there. These stupid examples always show closing result sets and statements, etc. by copying the 'close' methods from one SQL to another. Are these people idiots? If you have repeated code, put it into a method! Don't just copy/paste as they have in the JDBC 'examples' they show there. Better yet, you can just make a class for each SQL that implements an interface, and have an another class manage the connection/exception handling, closing, etc. Any decent Java developer can crank this out in a half-hour. You don't need all this 'injection' based crap to reduce some of the verbosity of JDBC. It takes *far* less time to just build your own utilities than to read through *huge* books on Spring/Aspect oriented programming/IOC (and all the other academic bullcrap). Mike
  149. Give me a break. I've alredy written my own JDBC utilities (as have most developers) that require less code than the Spring example there
    Nice! Could you please open-source your marvellous solution so we all can benefit from your great work? I mean, it is so much better than Spring or other academic crap out there, it would be too selfish of you to keep it to yourself.
  150. I've alredy written my own JDBC utilities (as have most developers) that require less code than the Spring example there.
    I've used Spring JDBC to retrieve stuff from the database with one line of code. I doubt you could write anything that did it in less code. And most of the "JDBC utilties" that I see other developers write just convert everything to Strings and return it that way.
    You don't need all this 'injection' based crap to reduce some of the verbosity of JDBC.
    You're obviously not familiar with Spring or Spring JDBC at all if you think you need 'injection' to use the Spring JDBC code. I've successfully used it in projects without using the IoC container.
  151. I've used Spring JDBC to retrieve stuff from the database with one line of code. I doubt you could write anything that did it in less code. And most of the "JDBC utilties" that I see other developers write just convert everything to Strings and return it that way.
    No, I think you haven't realized the possibilities of abstracting JDBC. It's perfectly possible to get a populated bean with just one line of code without Spring.
    You're obviously not familiar with Spring or Spring JDBC at all if you think you need 'injection' to use the Spring JDBC code. I've successfully used it in projects without using the IoC container.
    That's the problem with Spring, when DI is criticized, some other "Spring-" is used as an argument. Spring it's for everything and it's for nothing, it's impossible to nail down a criticism because people keep dodging them just like you did.
  152. No, I think you haven't realized the possibilities of abstracting JDBC. It's perfectly possible to get a populated bean with just one line of code without Spring.
    Interesting. When you can't actually refute what someone claims you just say they don't understand or that they don't know how to code without Spring! I love the Internet. The guy said his stuff was better than Spring's. I can't prove him wrong because he isn't showing his stuff (but its somehow magically better). However, what I can tell you is that Spring JDBC has allowed me to do certain stuff with JDBC in one line of code. Could I write my own JDBC abstraction layer to do the same thing? Probably. Could my coworker? Probably. Could the guy at my next job? Probably. Could you? Probably. But if Spring JDBC meets my needs and the needs of my coworkers why would I want to write something else I need to maintain, bug fix, document, just so I could claim I'm not using Spring. If something really bothered me about Spring I would submit a patch with a suggested enhancement.
    That's the problem with Spring, when DI is criticized, some other "Spring-" is used as an argument. Spring it's for everything and it's for nothing, it's impossible to nail down a criticism because people keep dodging them just like you did.
    Uhm actually, the problem with people is some of them never read. If *you* had bothered to read before criticizing you would have noticed that person stated that Spring JDBC required DI. I merely corrected that statement because its obviously not true. Debating the merits of tools and frameworks is valuable and a worthwhile thing to do. However, it only works when both sides actually understand what the tool does and bothers to read what the other person writes.
  153. Re: less frameworks == better[ Go to top ]

    Mike
    Better yet, you can just make a class for each SQL that implements an interface, and have an another class manage the connection/exception handling, closing, etc. Any decent Java developer can crank this out in a half-hour. You don't need all this 'injection' based crap to reduce some of the verbosity of JDBC.
    I doubt you are interested in reasoned argument, given the "crap" comment, but here goes anyway... With a little research, you would have been aware that the Spring JDBC functionality is independent of Spring injection capabilities--it's a class library that of course works nicely with an injection framework (as a huge amount of existing Java code does, because injection is designed to facilitate natural idioms). Spring is cleanly separated into modules, so you only need to use the parts that are relevant to your needs. For example:DataSource ds = getMyDataSourceFromJndiOrSomeplaceElse(); JdbcTemplate jt = new JdbcTemplate(ds); int userCount = jt.queryForInt("select count(0) from t_user"); No injection in sight. (Of course most people who try it conclude that injection is way better than explicit lookup, but that's another discussion...) Now that's not a lot of code, and consider the kind of things you get for free, beyond connection management:
    • configurable awareness of SQL warnings
    • ability to trivially configure Spring to unwrap native JDBC artifacts in advanced cases (e.g. to use Oracle-specific APIs), regardless of what connection pool may be in use
    • transparent unpacking of vendor codes, so you gain portability and readability (no need to know the ORA code for a particular condition and then find that code doesn't work in another database, for example)
    • simple, portable BLOB handling
    • support for batching statements with a consistent API
    • portable and simple support for stored procedure handling, even advanced cases such as stored procedures returning result sets
    ...and I could go on. All of which make your enthusiasm for writing your own stuff--and the vehemence of your comments--puzzling, unless you have never encountered any of these requirements. Regarding the history of Spring JDBC and my motivation for writing the original version (since improved by Spring developer and DBA Thomas Risberg and others): I have worked on and reviewed dozens of projects over the years, before and after developing Spring. The vast majority do not use any worthwhile abstraction. Incredible, but true. The majority of abstractions I've seen in projects not using Spring are broken (at least in corner cases), and much harder to use than the Spring approach. For example, Spring JDBC makes the starting point the javax.sql.DataSource API available from an app server or standalone connection pool; most other abstractions I've seen start from Connection and thus are more complex to use. Rgds Rod
  154. Re: less frameworks == better[ Go to top ]

    Well, you learn something everyday. When I started reading about Spring, the article I was reading started off with IoC and Aspect oriented programming (aspect oriented programming seemed like a 'solution' without a problem). I stopped there. The fact that your JDBC utilities don't use injection is good. So if my comments about Spring being an 'abomination' were a little harsh, sorry. I guess everyone is in to the 'touchy, feely' stuff these days. Sheesh. Nevertheless, my original point stands... Just because you have worked on a lot of projects where the 'in house' JDBC utilities were sucky does not mean that everyone elses are. I have developed some JDBC utilities that I feel are better. I can generate a type safe collection of SQL results in one line of code. Additionally, I've developed some utilities that allow for the creation of extensible queries where I can start with a base query and easily add columns, tables, joins, and filter conditions or override them in subclasses (originally got the idea from Paul Lee). In applications where you've got many large and slightly different SQL's, this is extremely useful. Why should I use what Spring has when what I already have works well? No, my stuff does not do everything that Spring does, but it does what is needed and does it well. I don't want to carry the baggage of a complex framework just because the self promoting yahoos and SpringBots here think I should. Besides, JDBC 4 makes many of the features of Spring obsolete, particularaly the exception handling. Mike
  155. Re: less frameworks == better[ Go to top ]

    Well, you learn something everyday. When I started reading about Spring, the article I was reading started off with IoC and Aspect oriented programming (aspect oriented programming seemed like a 'solution' without a problem). I stopped there. The fact that your JDBC utilities don't use injection is good. So if my comments about Spring being an 'abomination' were a little harsh, sorry. I guess everyone is in to the 'touchy, feely' stuff these days. Sheesh.
    It's important to understand things before trying to claim they have no value. I would suggest also that you put more effort into trying to understand AOP and the problems it solves. You may not agree on the solution, but the problem is certainly real, and many technologies have attempted to solve it, not just AOP and Spring...
    Just because you have worked on a lot of projects where the 'in house' JDBC utilities were sucky does not mean that everyone elses are.
    No, it does not mean that everyone else's approach is poor. However, given that this experience spans a lot of industries, it's quite reasonable to extrapolate that most approaches to JDBC out there are poor. No one said that Spring needed to be used in all cases; I would merely say that Spring JDBC has produced significant benefits to tens of thousands of users, and I'm not sure why you think that's a bad thing.
    I have developed some JDBC utilities that I feel are better.
    Maybe your JDBC stuff is great. I don't know, as I can't see it and test it, so I won't comment. However, the point is that you felt the need to comment aggressively and negatively about Spring's JDBC functionality, which you obviously hadn't looked at. If you feel your JDBC stuff is so much better, maybe you should make that available, and then we could discuss it.
    I don't want to carry the baggage of a complex framework just because the self promoting yahoos and SpringBots here think I should.
    I'm still not sure why you feel so strongly about this, without any direct experience of Spring. If you don't want to use Spring, don't use it. Attacking people who have had a positive experience with it, and making statements about "baggage" and "complexity" that aren't backed up (and were clearly wrong in this case) is not useful. Rgds Rod
  156. Re: less frameworks == better[ Go to top ]

    Well, you learn something everyday. When I started reading about Spring, the article I was reading started off with IoC and Aspect oriented programming (aspect oriented programming seemed like a 'solution' without a problem). I stopped there. The fact that your JDBC utilities don't use injection is good. So if my comments about Spring being an 'abomination' were a little harsh, sorry. I guess everyone is in to the 'touchy, feely' stuff these days. Sheesh.

    It's important to understand things before trying to claim they have no value. I would suggest also that you put more effort into trying to understand AOP and the problems it solves. You may not agree on the solution, but the problem is certainly real, and many technologies have attempted to solve it, not just AOP and Spring...


    Rgds
    Rod
    AOP, I think, is the most daunting challenge of the Spring Framework, similar to pointers in C. Here is the article that started me on my road to understanding... Memoization in Java using Dynamic Proxies This article preceeded my use of Spring by nearly a year, so it has nothing do with "cool features" or using something in Spring just because it was Spring. It had everything to do with recognizing from years of working, the impact of what we now call cross-cutting concerns on code and how incomplete the solutions I've tried, seen, or heard of, seemed to be. This article helped me write my first proxy-based Security manager to handled application security independently from the business code. Later, I moved over to Spring AOP. We now use Spring's AOP for - Application security - Caching - Profiling - Exception handling consolidation - Don't have a name for this, but if certain operations involving 3rd party systems with which we integrate fail, we use an interceptor to retry the operation a every configurable interval for a configurable number of times - Error notification - When certain exceptions occur, the system emails(configurable, and with the customers consent) errors to our support with app version, build number, date, stack trace, and user information. We've had a solution("Oh, your data migration missed a column.") sent to the customer before a problem report was even opened. Most of these features are reusable across many projects, and all can be extended for specific projects. None impact the business tier and all can be turned on or all with a simple configuration file change of the Spring XML. AOP is a worthy addition to any developer's toolkit.
  157. Re: less frameworks == better[ Go to top ]

    However, given that this experience spans a lot of industries, it's quite reasonable to extrapolate that most approaches to JDBC out there are poor.
    Baloney. Sure some use it badly, but don't assume that most approaches are crap.
    I don't want to carry the baggage of a complex framework just because the self promoting yahoos and SpringBots here think I should.

    I'm still not sure why you feel so strongly about this, without any direct experience of Spring. If you don't want to use Spring, don't use it. Attacking people who have had a positive experience with it, and making statements about "baggage" and "complexity" that aren't backed up (and were clearly wrong in this case) is not useful.
    I'm not attacking anyone (please re-read my previous posts). If people have a positive experience with Spring, great...more power to them. If people want to use sub-optimal utilities in thier code, that is their choice. There are better approaches out there that people could use instead of Spring. My statement about complexity is not 'clearly wrong'. From what I've looked at, the Spring way of doing things is more complex than my way. How can you say that when you have not even seen my utilities? I don't care about Spring one way or the other, I'm just against the fanatical zealotry of the Spring advocates who claim to have the 'one true path' to writing good code, when that is clearly not always true. Mike
  158. Re: less frameworks == better[ Go to top ]

    However, given that this experience spans a lot of industries, it's quite reasonable to extrapolate that most approaches to JDBC out there are poor.

    Baloney. Sure some use it badly, but don't assume that most approaches are crap.

    I don't want to carry the baggage of a complex framework just because the self promoting yahoos and SpringBots here think I should.

    I'm still not sure why you feel so strongly about this, without any direct experience of Spring. If you don't want to use Spring, don't use it. Attacking people who have had a positive experience with it, and making statements about "baggage" and "complexity" that aren't backed up (and were clearly wrong in this case) is not useful.

    I'm not attacking anyone (please re-read my previous posts).

    If people have a positive experience with Spring, great...more power to them. If people want to use sub-optimal utilities in thier code, that is their choice. There are better approaches out there that people could use instead of Spring.

    My statement about complexity is not 'clearly wrong'. From what I've looked at, the Spring way of doing things is more complex than my way. How can you say that when you have not even seen my utilities?

    I don't care about Spring one way or the other, I'm just against the fanatical zealotry of the Spring advocates who claim to have the 'one true path' to writing good code, when that is clearly not always true.

    Mike Well, name them. No one here is married to Spring. Many of use have written code BEFORE Spring and will do so afterward. If you know of something better, point us to it. You claim that your utilities are good, so let's see them. Put them out here in the broad light of day. For someone who doesn't care abuot Spring one way or the other, you seem to have a lot to say about it. In fact, most people, myself include, WHO ACTUALLY USED SPRING, admit that there is nothing revolutionary about Spring. As I've posted, I even used my own Dynamic Proxy classes before Spring. I even posted the article that kickstarted my efforts. We all freely admin that Spring encourages a cleaner approach, which is a far cry from saying "The Spring approach is better(or cleaner)". In addition, Rod said, quite clearly, that he couldn't comment on your stuff BECAUSE your stuff isn't publicly available and he's never seen it. So, make it available and let the market speak.
  159. Re: less frameworks == better[ Go to top ]

    I'm not attacking anyone (please re-read my previous posts).
    We've had "abomination", "crap", "bullcrap", and "SpringBots" and "self-promoting yahoos" thus far. Not to mention "baloney" and "fanatical zealotry". I guess if you want to attack something or someone you must really get worked up.
  160. Re: less frameworks == better[ Go to top ]

    I'm not attacking anyone (please re-read my previous posts).

    We've had "abomination", "crap", "bullcrap", and "SpringBots" and "self-promoting yahoos" thus far. Not to mention "baloney" and "fanatical zealotry". I guess if you want to attack something or someone you must really get worked up.
    "Abomination", "crap" and "bullcrap": Were directed at some of the Spring concepts, not at any people or groups of people. "Springbots", "fanatical zealotry", and "self-promoting yahoos": Were directed at some of the Spring advocates. "Baloney": Used accurately. Mike
  161. Re: less frameworks == better[ Go to top ]

    I think the Java folks did wrong when they got away from simple Servlets/JSP and JDBC.


    That would imply the following:

    1) All functionality needed in all J2EE applications can be addressed by using solely Servlets/JSP and JDBC.

    2) The solution provided by those three technologies is always simpler than with a more advanced/complex one.

    I think anybody who has worked in complex environments (highly transactional, resource intensive etc...) would probably disagree with 1).

    As for 2), just compare the JDBC code you have to write in a "simple" appplication vs the one you have to write in Spring:

    http://www.oracle.com/technology/pub/articles/marx_spring.html

    Give me a break. I've alredy written my own JDBC utilities (as have most developers) that require less code than the Spring example there.

    These stupid examples always show closing result sets and statements, etc. by copying the 'close' methods from one SQL to another. Are these people idiots?

    If you have repeated code, put it into a method! Don't just copy/paste as they have in the JDBC 'examples' they show there.

    Better yet, you can just make a class for each SQL that implements an interface, and have an another class manage the connection/exception handling, closing, etc. Any decent Java developer can crank this out in a half-hour. You don't need all this 'injection' based crap to reduce some of the verbosity of JDBC.

    It takes *far* less time to just build your own utilities than to read through *huge* books on Spring/Aspect oriented programming/IOC (and all the other academic bullcrap).

    Mike
    Here is the problem. I don't want to use YOUR utilties. I don't want to use a different set of utilities for every project. Just your "classes for every SQL, closing, etc.." is already more stuff I has to be written. No one is saying that a person could not write what is in Spring. I had factories before Spring, for example. I also had my own Dynamic proxy implementations. I also had code that read my own XML based configuration files. But now I had to maintain all of the above, document all of the above, and enhance all of the above when more features were needed. You say you can crank out that code in .5 hours. Does that include documentation? All that goes out the window. Instead of maintaining documentation on factories, proxies, and jdbc layers, I can point people to a Spring or Hibernate book and REAL work gets done. When I first tried Spring, my original intent was to just use it as a factory. It was so easy, I expanded my usages. It took my 1 day to port my proxies to Spring's AOP. But that's me... It seems to me that most of the people arguing for all custom, don't work in groups because they seem to ignore items like consistency and documentation.
  162. Give me a break. I've alredy written my own JDBC utilities ...These stupid examples always show closing result sets and statements, etc. by copying the 'close' methods from one SQL to another. Are these people idiots?... You don't need all this 'injection' based crap to reduce some of the verbosity of JDBC.

    It takes *far* less time to just build your own utilities than to read through *huge* books on Spring/Aspect oriented programming/IOC (and all the other academic bullcrap).

    Mike
    Where did you get the idea that the "injection based crap" as you put it so elegantly, was necessary for JDBC Spring? Seems to me you're yet another Spring critic expert with no knowledge of Spring. If you don't have the desire nor the need to read about a framework, that's fine. If you feel that you do not need it, then don't use it. Just don't go on a meaningless rant spitting insults and incorrect statements. That's annoying and reflects badly on you.
  163. Re: less frameworks == better[ Go to top ]

    I just don't get it.
    I hear McDonalds is hiring. :)
  164. Congratulations on 2.0[ Go to top ]

    I just converted one of my apps from Spring 1.2 to 2.0, and it was a piece of cake. You folks really did a quality job. Everything was backward compatible with my Spring 1.2 stuff. I migrated to the Spring schema and some of the new tags, no problem. Spring/Hibernate worked with no changes, as did DWR/Ajax. And the documentation is great. I wish all open source projects had this kind of quality. Thanks!