It is a common misconception that I hear when talking with clients that all information about generic types is erased from your Java class files. This is entirely untrue. All static generic information is maintained, and only generic information about individual instances is erased. So if I have a class Foo that implements List<String>, then I can determine that Foo implements the List interface parameterised by String at runtime. However, if I instantiate an instance of ArrayList<String> at runtime, I cannot take that instance and determine its concrete type parameter (I can determine that ArrayList requires type parameters). In this entry I’m going to show you a practical usage for some of the available generics metadata that simplifies the creation of strategy interfaces and implementations that differ by the type of object they process.
The Spring Blog
I am very excited to announce that the Spring SIG within the New England Java Users Group will be having our first meeting this Thursday (September 28th, 2006). Ramnivas Laddad (author of AspectJ in Action and Interface21 Principal) will be presenting "AspectJ for Spring Developers". This will be a great chance to learn about the enhancements in AspectJ integration within Spring 2.0.
You can read the details HERE, and be sure to click on the 'Register' link on the left-hand side of the page if you plan on attending.
A couple of weeks ago, the Spring Framework project passed 1 million downloads from its home on SourceForge. The true total is probably much higher, as this figure does not include nightly builds or the other sites from which Spring can be downloaded. And, of course, Spring is included in the distributions of a large and growing range of other products. And then there’s Spring.NET…
Most important, Spring continues to gain momentum: the numbers are growing very rapidly. The most downloaded version of Spring is the most recent production release, 1.2.8, which has been downloaded 175,000 times–that is, over 17% of the total. At this rate we will achieve our next million downloads much faster than the first million!
Welcome to my new blog! I haven’t blogged since August 2004, but have been inspired by our new team blog to try to lift my game. I’ve also been shamed by the blog-energy of my colleagues.
I’m very excited about a lot of topics at the moment, and promise to blog much more often than once every 2 years in future… Stay tuned for my thoughts about Spring 2.0 and beyond, OO design, AOP, and the future of enterprise Java.
In the meantime, I’ll share my travel schedule for the next few months (which will at least give me an excuse for not always posting regularly):
First and foremost, we are committed to supporting Spring users who are using Maven as their build system of choice. This means we will help ensure accurate POMs are available in the Maven repository with each Spring release starting with Spring 2.0 RC4. That is what the world’s most most popular JIRA issue is all about. Nothing more.
Spring Framework 2.0 RC4 has been released. This is the last release candidate before Spring 2.0 final, and you may find out more about it from the release announcement itself as well as the JIRA issue list for a complete list of changes in this release.
Possibly the most important thing to watch out for is that this release introduces versioned file/location names for the 2.0 DTD and Schemas (XSDs). This was necessary since the XML bean definition format was significantly enahnced for 2.0, but 1.2.x users still need to be able to refer to the 1.2.8 DTD. Here is an example of using the 2.0 “beans” schema (2.0 ships with a number of other new schemas as well, representing various special namespaces):
This is the last release candidate before Spring 2.0 final. RC4 includes many further bug fixes and refinements in various areas, as well as minor new features (for example in the JMS support). Please see the changelog and JIRA issue list for all the details. The most notable changes include…
New and Noteworthy
- This release introduces versioned file names for the 2.0 DTD and XSDs. Please adapt your bean definition files if they build on the 2.0 XSDs on or 2.0-specific DTD features. For example:
Acegi Spring-WS Spring Web Flow
That said, it’s not quite time for celebration. Converting the last two projects (Spring and Spring Web Flow) are non-trivial tasks (just take a look at Better Builds with Maven if you don’t believe me). As such, the conversion is not something that we really want to do this close to the major 2.0 and 1.0 releases. What I can tell you is that the conversion is a goal scheduled for after the releases.
It started out as a small thing. Just a hunch of mine that Spring and OSGi should sit together very well. The idea was that by enabling Spring applications to be deployed in an OSGi runtime, we could bring better modularity, versioning, runtime deployment and update capabilities to Spring applications. It’s a project I never really advertised; I just started experimenting, talking to a few people, and writing some early prototype code.
It turns out that a lot of people seem to be interested in Spring and OSGi. We have a collaboration ongoing with representatives from BEA, Oracle, IBM, Eclipse, the OSGi Alliance, and several others to build a shared model of how Spring support for OSGi should look, and how we can make it easy to build enterprise applications on the OSGi runtime. The most recent version of the specification is attached to Spring JIRA issue 1802. Here’s a direct link to the specification text. I ran a workshop in London a couple of weeks ago where we got several of the key players together and made some excellent progress. Peter Kriens (OSGi Technical Director) has a write-up here.
As most of you know, one of the big improvements in Spring 2.0 is the addition of the AspectJ pointcut language and better integration with AspectJ in general. While I think everyone believes that this will be a great benefit in the long run, it has led to some issues. We’ve found that there are certain behaviors that Spring AOP has always done, that AspectJ has never done.
One of the big issues that cropped up was the behavior of Before advice. If you’ve used Spring AOP in Spring 1.x you probably know that Spring allows you to change argument values before they are passed to the target method. What you may not know is that AspectJ has never allowed this behavior.