Release Announcement: 13/11/2009

5 cool things available in Spring 3.0

1. Java 5 fully used throughout the whole API. In 2.5 the core is still Java 1.4 compatible, 3.0 is written in and requires Java 5.0. This means much greater use of generics. Unrelated but they have also included many performance enhancements.
2. SpEL. Spring Expression Language gives access to nested bean definitions and system properties via #{…} syntax in property values. These dynamic #{…} expressions and static ${…} placeholders can also be used to inject property settings via the @Value annotation. This should much simplify property setting.
3. Comprehensive REST support. Spring 2.5 MVC is an excellent pattern. The simplicity of annotated controllers results in very clean implementations. 3.0 takes this system further by building in Restful support and a RestTemplate for clientside REST.
4. Spring 3.0 UI Field Formatting. Springs formatting system has always been useful in web and desktop applications. Its an effective way to remove a lot of boilerplate code from a system. This new system of annotations allows common formats to be applied to classes, model properties and methods. Check it out its very cool.
5. Many enhancements migrating to java.util.concurrent including ThreadPoolExecutorFactoryBean which exposes the native ExecutorService interface. The concurrent package is very good indeed, so bringing more support into spring is just fantastic.

Of the 5 mentioned here its only the tip of the iceberg as regards new features. This release is very rich. As usual with spring its when you have something to solve that you really appreciate it.

                          

Steps taken to refactor

There was actually very little to do.

Step 1, add a maven dependency

            com.google.collections
            google-collections
            1.0-rc3
            jar

Step 2, replace the array with an ImmutableList

private static final LineResult[] EMPTY_LINERESULT_ARRAY = new LineResult[0];
private LineResult[] lineResults = EMPTY_LINERESULT_ARRAY;

could become:

private List<LineResult>  lineResults = ImmutableList.of();

In the end I used ImmutableList to clearly my intent. The usage is internal to the class so there is no advantage in using the List interface.

private ImmutableListst<LineResult>  lineResults = ImmutableList.of();

Step 3, The constructor and static factory methods are simplified
We are no longer using an array to back the list, so the protective copy can be moved from the constructor into the static method. This reduces the window of vulnerability you are exposed to before capturing the data held in the list. This is a direct result of the google class providing a static factory method. Nb. Its a shame that the standard collections don’t provide static factory methods.

Prior to the changes the protective copy was done in construction like this.

 this.lineResults = lineResults.toArray(EMPTY_LINERESULT_ARRAY);

This result is a much simpler constructor.

private ResultsFileSearch(File fileFound, ImmutableList<LineResult> lineResults) {
        this(fileFound);
        this.lineResults = lineResults;
}

My newInstance method makes use of the ImmutableList.copyOf static factory method resulting in a very clean conversion of List into Immutable list. Note that generics is inferring the type.

public static ResultsFileSearch newInstance(File fileFound
                 , List<LineResult> lineResults) {
        return new ResultsFileSearch(fileFound
                        ,ImmutableList.copyOf(lineResults));
}

Step 4, the getLineResults method no longer has to deal with the array or conversion.
The original array backed object had to deal with returning either an empty list or conversion to an unmodifiable list. There are two things I did not like about this when I wrote the original.

• The code has to check the array resulting in some conditional logic. This increases the test overhead slightly.
• The use of Collections.unmodifiableList(Arrays.asList(lineResults)); is very ugly and slow.

This was the original, note the subtle bug when returning an empty list.

 public List<LineResult> getLineResults() {

        if ((this.lineResults.length == 0)) {
            return Collections.emptyList();
        } else {
            return Collections.unmodifiableList(Arrays.asList(lineResults));
        }
        return this.lineResults;
}

I hope you agree its a much simpler version using the google code. As we are now using the Immutable implementation, we don’t have to worry about exposing the reference.

public List<LineResult> getLineResults() {
        return this.lineResults;
}

Conclusions

Using the google collections makes my implementation much cleaner. Several complexities are given over to the google collections classes. Moreover testing of my class is simpler. The changes are contained within the class. None of the method signatures change, which has two consequences. On the plus side the re-factor is contained within this class. On the negative side, any code modifying the list will raise an UnsupportedOperationException which was no different to my original version. The construction of my class might be slightly slower, the memory overhead slightly bigger now that we are not using the array. Counter to this, the getLineResults method is quicker as it now only returns a reference. In my program this is more important as architecturally it uses bounded queues to hold these objects for processing by threads. So although its using a little extra memory, its constrained. The performance gain is worth it.

I recommend using the com.google.common.collect package but adhere to the caveats i.e don’t expose the types in an API etc.