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
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!
2 comments:
You comment that OSGi has to go through many growing pains in the Enterprise market. Could you give some concrete examples?
We have gone through a requirements phase in the OSGi and have found very few deficiencies in the core. There are obviously many interesting optional functions to add but I am curious why you think OSGi requires more maturity after almost 10 years ...
Kind regards,
Peter Kriens
Peter,
I am not faulting OSGi in these comments.
Enterprise apps have been developed for years without OSGi. Libraries used in enterprise development have been developed for years without OSGi. When you have libraries and frameworks which have idiosyncrasies designed for a pre-OSGi world - I'm thinking of classloaders mostly, but also coding and library design conventions - it is not always straightforward to retrofit these into a new technology where these tweaks are not relevant.
On to the examples. I understand that it is difficult to get Hibernate to work with OSGi. Hibernate, for it's faults, is more established in Java enterprise world than OSGi. Another is in the export of packages. Libraries work better with OSGi if they separate put their interface and implementation classes in separate packages. This of course is good practice, but library developers would not necessarily have paid such close attention to it in a pre-OSGi environment. Another example, I understand, is there are difficulties with OSGi and marshalling RMI. Another example is bundles: where am I going to get OSGi compliant bundles for libraries, nicely set up to export all necessary packages, for all the libraries I use on a day to day basis? Perhaps there is a Maven-style repository somewhere which reflects all the necessary hard work - done - but I somehow doubt it.
Unfortunately for me, I don't understand enough about these problems to know how much of a problem they are, or indeed whether they are problems at all.
My concrete examples are based largely on anecdotal evidence, based on speaking to people who have had real experience. But therein lies the problem - the immaturity of OSGi is largely an immaturity of knowledge, rather than the technology itself. Most of the developers I work with in my day job have never heard of OSGi, let alone used it. At the Spring exchange I don't remember seeing more than a handful of hands go up when people were asked if they had used OSGi (of course, everybody uses Eclipse, but that's different).
My impression, and I have to confess it is only an impression, is that there is still a plenty of pain to go through, plenty of best practices to figure out, and plenty of conceptual hurdles to leap before OSGi is a smooth out the box experience which truly delivers without draining productivity. A couple of books on the subject would be nice!
In the meantime, somebody still has to go through the pain. At the end of the day, I'm sure we will all decide that it has been worth it.
For me, it is not a question of the immaturity of OSGi, but of the maturity of combination of OSGi as and existing enterprise libraries as a potential lingua franca of Java enterprise development.
I don't mean to sound negative. It's a good thing for OSGi that after all these years, it's threatening to make the breakthrough. But don't expect it to be painless.
Regards,
Phil
Post a Comment