In Minnesota, winter is a long hard season. We usually don’t start thinking about spring until the lakes unfreeze and fishing season begins – that’s May those unfamiliar with the territory.
But this year, Spring of a different nature arrives early. The Spring I am speaking of is the Spring Framework. Spring Framework 3.0 Milestone 1 is out (download it here), arriving in December ’08 with the final release expected… no pun intended… this spring. Major additions and changes include: requiring Java 5 and J2EE 1.4, support for RESTful Web Services, the introduction of Spring expression language (EL). To learn more about Spring 3.0, I point you to the blog and web site of the experts.
However, what I found very interesting about Spring 3.0 can be found in the Spring MVC module. In Spring 2.5, the Spring MVC framework adopted annotation-based controllers as an alternative to the large hierarchy of Spring MVC controller classes (see diagram below).
In fact, these annotation-based controllers were just one of many “stereotype” annotations. Components with stereotype annotations (let’s call the stereotypical components) are meant to clearly identify the components serving in each role of the application – especially as it relates to the model-view-controller rolled environment. The drive behind stereotypical components is that these classes do not have to extend any base class or reference a Spring, Servlet, or other API. One thing about the Spring Framework – it has always embraced loose coupling!
With the Spring Framework 3.0, I was surprised to find that the intent of the Spring project team is to take this shift in design to the next level – and to do it NOW. The MVC controller hierarchy that many in the Spring development community have become familiar with (and embraced over Struts or JSF in many cases) is being deprecated in favor of the new annotation/stereotypical model. Read the following quote from Rod Johnson (Spring founder, project lead and CEO of Spring Source) from an interview with InfoQ on Jan 22nd.
In Spring framework 3.0 there will be a number of deprecations, for example, the old MVC controller hierarchy. We view the Annotation based Spring MVC usage model that we introduced in Spring 2.5 is being a far superior replacement. That will be deprecated in Spring framework 3.0 and in the next version, whether it's 3.1 or 4.0, those classes will be removed. We don't approach deprecation the way some seem to approach deprecation, which is "Let's put a message into it" that will take years when they compile a code. Our view on deprecation is that it is a serious statement of intent. If we deprecate something we are saying "Hey, guys, it's time to think getting off this because we don't think it's a good usage model anymore." There will certainly be a bit of - if you like - Spring cleaning in the next release after Spring 3.0. Probably the most obvious part will be the Spring MVC controller hierarchy.
I applaud the Spring team for its position on deprecation. On every project I have been on, it seems there is at least one consultation with a novice developer about why using many of the java.util.Date methods is a bad idea. While Sun deals with a different extent of concerns and legacy support, I often wonder when, if ever, we’ll see Java deprecated classes and methods leave the JDK.
However, I am anxious to see how the Spring community embraces this large change. A lot of applications have been built with Spring MVC. In large enterprise applications that have embraced Spring MVC, the “spring cleaning” may not be easily accomplished. Many of us have seen development shops stop upgrading a framework environment because of backward compatibility issues. In corporate environments, there is usually little appetite (read money) for upgrading frameworks and addressing backward compatibility issues. It can push an application under the label “legacy” too quickly.
And while the entire Java community is embracing annotations as a gift from above, I often wonder if application architects and lead developers have stopped to examine potential hazards of them as well. Mike Keith posted an excellent exploration of some of the general pros/cons regarding annotations that all should take a look at. Dave Minter and Jeff Linwood have also addressed some of the pros and cons as they relate to Hibernate’s use of annotations in their book Beginning Hibernate. Although these articles may be somewhat dated and not commenting on Spring annotations, architects and developers would benefit from a quick glance to see if some arguments (and potential issues) apply to their Spring world?
Before someone takes this posting as a diatribe against Spring, Spring MVC or annotations, allow me to caveat. As a 20 year veteran of software development and as educator of those entering our ranks, I have taken the view that it is the responsibility of any developer to inspect all sides of a software problem and solution. As I tell my students, there is no free lunch in software engineering. There are always pros and cons (I joke that those that do not believe or understand that are called sales people or consultants). An understanding of those sides is critical to success in our business. In the case of Spring MVC annotations, there is a lot on the pro side as well; ...did I mention the loose coupling?
So, what’s your take? Will the Spring stereotype model and MVC annotations help your world? If so why? If not, again why? I welcome your thoughts and comments.
If you are looking at Spring and want to learn more, I encourage you to join me in the classroom for our Complete Spring class.
But this year, Spring of a different nature arrives early. The Spring I am speaking of is the Spring Framework. Spring Framework 3.0 Milestone 1 is out (download it here), arriving in December ’08 with the final release expected… no pun intended… this spring. Major additions and changes include: requiring Java 5 and J2EE 1.4, support for RESTful Web Services, the introduction of Spring expression language (EL). To learn more about Spring 3.0, I point you to the blog and web site of the experts.
However, what I found very interesting about Spring 3.0 can be found in the Spring MVC module. In Spring 2.5, the Spring MVC framework adopted annotation-based controllers as an alternative to the large hierarchy of Spring MVC controller classes (see diagram below).
In fact, these annotation-based controllers were just one of many “stereotype” annotations. Components with stereotype annotations (let’s call the stereotypical components) are meant to clearly identify the components serving in each role of the application – especially as it relates to the model-view-controller rolled environment. The drive behind stereotypical components is that these classes do not have to extend any base class or reference a Spring, Servlet, or other API. One thing about the Spring Framework – it has always embraced loose coupling!
With the Spring Framework 3.0, I was surprised to find that the intent of the Spring project team is to take this shift in design to the next level – and to do it NOW. The MVC controller hierarchy that many in the Spring development community have become familiar with (and embraced over Struts or JSF in many cases) is being deprecated in favor of the new annotation/stereotypical model. Read the following quote from Rod Johnson (Spring founder, project lead and CEO of Spring Source) from an interview with InfoQ on Jan 22nd.
In Spring framework 3.0 there will be a number of deprecations, for example, the old MVC controller hierarchy. We view the Annotation based Spring MVC usage model that we introduced in Spring 2.5 is being a far superior replacement. That will be deprecated in Spring framework 3.0 and in the next version, whether it's 3.1 or 4.0, those classes will be removed. We don't approach deprecation the way some seem to approach deprecation, which is "Let's put a message into it" that will take years when they compile a code. Our view on deprecation is that it is a serious statement of intent. If we deprecate something we are saying "Hey, guys, it's time to think getting off this because we don't think it's a good usage model anymore." There will certainly be a bit of - if you like - Spring cleaning in the next release after Spring 3.0. Probably the most obvious part will be the Spring MVC controller hierarchy.
I applaud the Spring team for its position on deprecation. On every project I have been on, it seems there is at least one consultation with a novice developer about why using many of the java.util.Date methods is a bad idea. While Sun deals with a different extent of concerns and legacy support, I often wonder when, if ever, we’ll see Java deprecated classes and methods leave the JDK.
However, I am anxious to see how the Spring community embraces this large change. A lot of applications have been built with Spring MVC. In large enterprise applications that have embraced Spring MVC, the “spring cleaning” may not be easily accomplished. Many of us have seen development shops stop upgrading a framework environment because of backward compatibility issues. In corporate environments, there is usually little appetite (read money) for upgrading frameworks and addressing backward compatibility issues. It can push an application under the label “legacy” too quickly.
And while the entire Java community is embracing annotations as a gift from above, I often wonder if application architects and lead developers have stopped to examine potential hazards of them as well. Mike Keith posted an excellent exploration of some of the general pros/cons regarding annotations that all should take a look at. Dave Minter and Jeff Linwood have also addressed some of the pros and cons as they relate to Hibernate’s use of annotations in their book Beginning Hibernate. Although these articles may be somewhat dated and not commenting on Spring annotations, architects and developers would benefit from a quick glance to see if some arguments (and potential issues) apply to their Spring world?
Before someone takes this posting as a diatribe against Spring, Spring MVC or annotations, allow me to caveat. As a 20 year veteran of software development and as educator of those entering our ranks, I have taken the view that it is the responsibility of any developer to inspect all sides of a software problem and solution. As I tell my students, there is no free lunch in software engineering. There are always pros and cons (I joke that those that do not believe or understand that are called sales people or consultants). An understanding of those sides is critical to success in our business. In the case of Spring MVC annotations, there is a lot on the pro side as well; ...did I mention the loose coupling?
So, what’s your take? Will the Spring stereotype model and MVC annotations help your world? If so why? If not, again why? I welcome your thoughts and comments.
If you are looking at Spring and want to learn more, I encourage you to join me in the classroom for our Complete Spring class.
No comments:
Post a Comment