Friday May 21, 2004
Friday May 21, 2004
[NFJS Denver] Bruce Tate and Intro to Spring I decided to stay in the same room after Dave Thomas's talk and attend Bruce Tate's talk on Intro to Spring. After looking through the slides, I realized that its possible I won't learn anything new - but I think I'll stick around for a 1/2 hour or so - just to hear Bruce talk. At the beginning of his presentation, he asked if anyone has downloaded Spring. Hmmm - I'm the only one in a room of about 35. Bruce then mentioned Spring books coming out in the next few months. Damn, he didn't mention Spring Live - I guess I have some more marketing to do! Bruce calls Spring's ApplicationContext a "container", but it's not really a container, but a "dictionary of instantiated objects." That sounds like a good definition to me. Spring's mission statements, or basic beliefs:
- J2EE should be easier to use
- It's best to program to interfaces, rather than classes. Spring reduces the complexity cost of using interfaces to zero.
- JavaBeans offer a great way of configuring applications
- OO design is more important than any implementation technology, such as J2EE.
- Checked exceptions are overused in Java. A framework shouldn't force you to catch exceptions you're unlikely to be able to recover from.
- Testability is essential, and a framework such as Spring should help make your code easier to test.
I've been working with Spring for long enough that I've actually forgot about how much easier my J2EE development life is. This session is a good reminder of how cool Spring is. Poor suckers in this room - no one is even using it. Bruce is a good speaker - and looks quite a bit younger in real life (than in his pictures).
OK, I'm outta here - time to go learn some more about CVS. Note to self - talk to Bruce and figure out how he modified JUnit's excluded.properties file. He had to do this a few weeks back in order to get Hibernate's EHCache working with Spring in JUnit tests. I was able to replicate his issue, but never solved it myself.
Posted in Java
at May 21 2004, 05:28:09 PM MDT
4 Comments
Search This Site
Recent Entries
- Wine Tasting in Napa Valley
- How to build a Shot-Ski
- Bus Project Update
- Farewell to the 2011-2012 Ski Season
- Cruising around the Western Caribbean
- Spring Break!
- A Spectacular Trip to Stockholm and Madrid
- Comparing Web Frameworks and HTML5 with Play Scala at Jfokus 2012
- Play Framework 2.0 with Peter Hilton at Jfokus
- Secure JSON Services with Play Scala and SecureSocial
Posted by Ed Hill on May 21, 2004 at 08:09 PM MDT #
Posted by Jason Bell on May 22, 2004 at 03:51 AM MDT #
Posted by Matt Raible on May 22, 2004 at 07:55 AM MDT #
At the end of the day you have to convice a board member of a company somewhere along the line that chaging from one whizzy technology to another is going to be worth the effort. I can see the first question from the board already, "Well Jase, you told us three months ago that Struts was going to solve all our problems, now you are saying Spring is better?"
What I would tell a board member is that using Spring will reduce time-to-market. Using Spring, it'll be easier for developers to deliver their projects on time and under budget. Spring simplifies J2EE development, and since it focuses on testability - this will likely result in higher-quality code. As for Spring vs. Struts - I would leverage the existing investment in Struts and not replace Struts with Spring's MVC framework. The can co-exist very nicely with each other. In fact, in the talk yesterday, not a single person was interested in Spring's MVC framework and most were using Struts.
Another reason to use Spring over something like EJBs is because your applications will be more portable. If you use a Spring+Hibernate solution, you can easily port your app to many database and many appservers. If you've designed your application correctly, you shouldn't need to change <em>any</em> application code. I'll admit that EJB is supposed to bring the same thing to the table, but we all know that EJBs are rarely portable across appservers. Even if they are, you usually have to dig into the JAR and change the deployment descriptor.
Posted by Matt Raible on May 22, 2004 at 10:11 AM MDT #