Spring Exchange 2008 in London

Today I attended the Spring exchange, held in London. Not only is it good to get away from the day job occasionally, but Spring is obviously the critical base technology for Impala, so an opportunity to get a quick, thorough and free update from the horse's mouth, as it were, is very welcome. Thanks to Spring Source and organisers Skills Matter.

Rod Johnson delivered the keynote, which as usual found another interesting angle to his perennial topic - the success of Spring. This time, the theme was the "The Changing of the Guard". It was all about the disruption that was taking place in enterprise development as a whole, with the leading technologies of yesteryear, J2EE and .NET, with their "One Size Fits All" approach, increasingly viewed as inadequate. A bleak future awaits J2EE, is his view. It's hard to disagree. Spring of course has pride of place in this future, evidenced for example by the continual upward rise of "Spring and Java" job adverts. As you would expect, he had some interesting ideas and perspectives. But I did feel like his talk went on a bit long ... I'm told it was 59 slides long!

The second talker was Sam Brannen, who went through the new features of Spring 2.5, fairly succinctly although without too much fanfare. Spring 2.5 now targets Java 1.6, fully supports JEE 5, and ships OSGi compliant bundles. However, the biggest areas of development in Spring 2.5 core are the use of annotations, in particular the myriad of ways they can be used to set up Spring bean definitions, effectively reduce the amount of configuration code that you need to write, but not without a few health warnings having thrown in.

Some of the annotation mechanisms include:

• JSR 250 common annotations, such as @PostConstruct, @PreDestroy and @Resource
• the Spring @Autowire annotation
• @Component, which identifies a class as a Spring bean

plus a whole bunch of others. While I am certainly a fan of annotations for specialised uses, such as in web frameworks such as Strecks, there is certainly the danger that such a sudden and vast proliferation of annotations will be confusing to many users. Personally, for most bread and butter bean definitions I think I will carry on preferring to use the basic XML definitions, with namespace support where appropriate.

On the whole, the annotations and new namespace implementations are really syntactic sugar which don't really tackle a real problem which remains with Spring: the absence of modularity as a first class concept at the heart of the framework. SpringSource aims to address this using OSGi, and I'm told that Spring OSGi will ship 1.0 next week. Nevertheless, Spring OSGi will not quite get to the crux of the problem, because a solution is needed now, and OSGi still needs to go through plenty of growing pains before it reaches maturity in the enterprise space.

The third talk before lunch was Dave Syer, who described the improvements to Spring's web offering. This is one area where they really have made impressive strides, and there is plenty more to come. Admittedly, it is also an area where some real catch up was necessary.

The bit I liked best was Spring @MVC, the new Annotation-based controllers, which combined the component scanning, offer a much neater way to wire up web applications. Couldn't help thinking back to my work on Strecks, and the similarity in the approach! JSF support is much improved, but I'm not terribly bothered about this. There's more AJAX'y stuff, and interestingly, gracefully degrading versions of the JSF components.

Both the afternoon sessions involved the impressive Adrian Colyer and Rob Harrop double act. One of the nice things about going to these kinds of conferences is you discover some unexpected things: this time, how they were using Eclipse MyLyn to group together different files used for different parts of their demos. A useful pedagogical technique. I liked Adrian's presentation on the internals of the Spring runtime, with some well crafted diagrams, and Rob had some good perspectives on how to use Spring in the field.

Something which really struck a chord for me was his advice on the structure of projects for large, complex applications, stressing the importance of modularity, and suggesting some practices for selecting between different configurations for development, testing and production. Yes, I'm back to my favourite themes: modularity and configurability, and of course, Impala. Not only does Impala bring modularity to Spring applications, but has some a couple of neat ways of tweaking module configurations without requiring any nasty build hacks.

Unfortunately, I didn't get to the final round table Q&A session due to home commitments, but if I had, I would have asked about Spring 3.0. There was surprisingly little spoken about Spring 3.0, and the plans they seem to have are evolutionary, not dramatic, at least as far as the core project is concerned.

A good day out, and I didn't even miss my train coming home!

Spring users: seven reasons why you'll like Impala

Here are seven reasons why you'll like Impala if you like already Spring:

1. Spring encourages interface based programming. Impala takes this one step further: modules communicate with each other using interfaces, and interface implementations are contained within modules.
   
2. Modules help you to organise your code, and eliminate unnecessary cross-code and cross-bean dependencies. Modules provide a much simpler mechanism for identifying high level relationships between parts of an application than is possible using raw application context definition files and relationships between individual beans.


3. What's not to like? There's virtually nothing that you can do in Spring that you can't do in Impala in exactly the same way as you would do it in vanilla Spring. You can still use virtually any of the Spring APIs, any Spring feature, technique, configuration mechanism, etc., unmodified! There's no new API or language to learn. You don't need to throw away any best practices. If anything, Impala makes it easier to enforce best practices, because it strongly encourages modular applications with well defined interfaces (based on Java interfaces).
   
4. A small learning curve. To start benefiting from Impala, all you need to do is organise you project according to a well defined set of conventions, and to add a bean definition into the relevant Spring context files. Otherwise, everything is the same.
   
   Impala is not asking you to embrace a new programming model, set of APIs or even language. Simply leverage your Java and Spring knowledge, but to greater effect.
   
5. Spring is great for test driven development in that it helps you manage dependencies better. Impala takes this a step further. The interactive test runner makes writing integration tests - still a pain point with plain Spring development - really easy, hence encouraging test driven development at every level.
   
6. Tasks such as reloading configurations, updating application logic, refreshing logging configurations are simple with Impala. Impala leverages Spring's first class JMX support to simplify these tasks.
   
7. Impala defines a convention-based project structure which makes sense both in terms of productivity and enterprise Java development best practice.
   

Spring's Petclinic Sample, Impala style

I've spent a bit of time converting the Spring Petclinic sample so that it runs with Impala. Petclinic it is actually a showcase for the various Spring data access technologies. I've cut down the Impala Petclinic sample to work with following configuration:

• data access using Hibernate
• MySQL database
• simple service and web tiers

To run the application, follow these steps:

• svn co http://impala.googlecode.com/svn/trunk/petclinic petclinic
• Open Eclipse, with the workspace set to the checkout directory (petclinic)

Now set up the database:

• First, from petclinic/db, run createDB.txt (as root). This creates the petclinic user
  mysql -u root -p < createDB.txt
• Then as the petclinic user, insert the tables
  mysql -u petclinic -ppetclinic petclinic < initDB.txt
• To insert data, run
  mysql -u petclinic -ppetclinic petclinic < populateDB.txt

To run the tests from Eclipse, simply run the main class AllTests as a JUnit test, which is in the project petclinic-tests.

To run up the web application, simply run the main class StartServer, which is in the project petclinic-web. This time, run it as a (main) Java application.

To run up the interactive test runner, run HibernateClinicTest as a Java application. Type u for usage. You can run this class as a standard JUnit test - it's part of the AllTests suite.

Next on my list is to create a sample based on Spring's Petstore sample (originally Clinton Begin's JPetstore application, a sample with a rather long history). This is more interesting, as it is a larger application with a greater variety of components, so should be an interesting showcase for Impala.

When will Impala be "go public"?

At the moment, there is still no public release of Impala. There have been no announcements on any popular web sites, to the Spring mailing lists or forums, or to any other public forum. This is deliberate. This is not because the necessary features are not present. Most of the functionality needed for a public release is present, and the code is usable and good quality. There is is enough functionality to provide real benefit to a project using Impala.

What still remains is to be absolutely sure that the Impala internal interfaces are correct. For the last few months (yes, literally!), I have been doing extensive refactoring, with the result that I am progressing towards this point. If users come up with a whole new set of requirements and ideas on how it can be used, there should be a clearly defined set of interfaces to build upon.

The first public release of Impala won't be just before going 1.0. However, it will only occur when I have reached the point that I am satisfied that the interfaces are as correct as I can make them, to support extensibility and maintainability moving forward. I think I am quite close. The interfaces are in pretty good working order, and the organisation of the code seems to make good sense.

I need to spend a bit more time working on the interactive test runner, and on deployment issues. Most of the work I've been doing with Impala has been within Eclipse itself. And of course, samples and documentation, although the first public release doesn't need to depend on these.

Impala and OSGi

The project most closely related to Impala is Spring OSGi, so it's tempting to try make some comparisons on the two projects, or at least on their approaches to solving the problems they are tackling. I should preface this by saying that I am talking from a certain position of relative ignorance: my understanding of Spring and OSGi is based mostly on what I have read in the documentation and a small amount of playing with samples some time ago. I've since been to a talk on OSGi at JavaWUG in London, and read a fair portion of the OSGi spec. I hope this has given me sufficient understanding to make a few remarks which reflect my impressions of the differences between Impala and the world of Spring OSGi.

Spring OSGi and Impala are tackling an overlapping set of problems

What Impala and Spring OSGi have in common is that they are both dynamic module based systems.

Impala provides a developer productivity solution through build support, an interactive test runner, and support for efficient, fast running integration tests.

OSGi, on the other hand, tackles a wider set of problems relating to visibility of classes. OSGi allows you to run multiple versions of third party libraries within the same JVM, which can prevent problems which may occur from different libraries depending on incompatible versions of the same third party library. You can think of OSGi as defining multiple class spaces for third party libraries as well as application code.

Impala makes a clear distinction between application code and third party libraries. There is only a single class space for third party libraries. If there is a clash between third party libraries, then you are no better off (or worse off, for that matter) than you would be in a standard Java/pre-OSGi world. You would still need to resort to whatever workaround would apply in that case.

While third party library clashes are certainly a theoretical possibility, it is quite rare in my experience to actually be a victim of such problems in a way which couldn't be addressed relatively easily through a simple workaround. Others may have different experiences in this regard. However, it does seem that there is quite a bit of overhead required to make sure that the Jars you use fit in nicely with OSGi requirements, so that they "play nicely" in OSGi world. It's the kind of overhead that I think most developers would look for ways to avoid for as long as they are able to do.

Impala has more of a focus on developer productivity

The purpose of Spring OSGi seems primarily to bring the benefits of OSGi to Java, via Spring. In that sense, it is OSGi centric. The fundamental trade-off with OSGi is one of productivity. Are you prepared to go to quite a lot more trouble in defining quite precisely the nature of dependencies between libraries, with the benefit that you will never get ClassCastExceptions due to classloader issues, and that you will be able to dynamically update library versions. Make no mistake, these benefits come at a cost. One very experienced OSGi developer described working with library dependencies OSGi as a "pain in the arse", something you wouldn't want to do without tool support.

Impala, by contrast, does not impose these kinds of constraints. In fact, it's very essence is about productivity. Dynamic module reloading can benefit productivity, because it means that integration tests can be written on the fly against a running application.

Impala Support for OSGi

Impala has all the internal interfaces necessary for seamlessly supporting OSGi, probably via Spring OSGi. I'm definitely considering adding this in the future. For the time being, that's not on the immediate horizon - getting the project into a publicly releasable form is a higher priority right now.

Impala being used on a "real" project

I'm pleased to say that I am now using Impala for what looks like may and should become a core and major development at the company where I am working. The results have been great. Progress has been more rapid than I have expected, and a lot of this is down to the capabilities provided by Impala.

I haven't run into any major obstacles that couldn't be overcome with relatively little effort. Dynamic reloading is working well. Test execution speed - a bugbear of the previous version - is quick. There are now around 200 tests, of which around 30 or so are integration tests which load up various bits of the application. The application currently consists of 21 Hibernate entities. Total execution time of all the tests - integration included- is about six to eight seconds for initial startup, plus the same again to run the tests.

It's a major moment for any open source project is when it gets its first real commercial user. In this case, the actual user is still primarily myself. That's a good thing - it means that on a day-by-day basis I am getting to validate the features and functionality, discover bugs when the appear, and get ideas for improvements and new features.

Successful open source projects are often extractions from existing successful commercial projects. Others are developed from a vision of the technology the developer would like to work with on his or her next project. Impala started off this way. The danger for the latter kind of projects is that the opportunities to use the technology in anger on real commercial projects may not present themselves that readily, with the danger that you don't get the chance to "eat your own dog food". At the moment, I am eating my own dog food by the spadeful, and it tastes good!

New package and domain names

I've been spending a bit of time working on the package layout of Impala classes. While the project is still at an early stage, it makes sense to try to get this right.

The first thing to do was to change the root package name. I've had to do this after moving the code from Java.net to Google code. The Impala root package is now org.impalaframework. It would have been nice to use org.impala, but I'm politely sticking to the convention that you should own the domain that you use (yes, I have actually bought the domain org.impalaframework!). I certainly didn't want to use com.googlecode; if I need to move the project again, then I don't want to have to do another root package rename. org.impalaframework is a bit wordy, but it at least there is a precedent in the form of the root package names used for Spring: org.springframework. Hope this doesn't make me too much of a copycat.

All this being said, the convention that you should to use a package name which corresponds to a domain name that you own kinda sucks. Of course, this is only a convention, and you can choose to ignore it. I may choose to do so, but for now, I'm more interested in getting the structure of the packages and classes right. That means getting the names of classes and packages right, getting their locations correct and eliminating package cycles. This process should settle down soon. It will need to before I'm ready to do the first public release.