I had the privilege of attending the SpringOne2gx conference this year in New Orleans. This is the first tech conference I have attended. Where I live, in Moncton, is a bit off the beaten path and is a bit far to travel to these types of conferences regularly. Past employers of mine have not always invested in their developers as much as they should. Thankfully, iWave Software was able to send me this year.
I had an excellent time at the conference and met a lot of smart and equally minded developers. There was plenty of great content at the conference and the Roosevelt hotel in New Orleans was a great place to host the conference. The food was amazing the the service top notch. On a whole the conference was a great experience.
For me, I made a Smörgåsbord of the conference taking a bit for all of the tracks that were provided. In the rest of this post I would like to cover some details on the plethora of technologies on display. Most of them were from SpringSource, the commercial company that backs the Spring technologies. There was a lot of great stuff but some of it I am a bit more skeptical on. The following are purely my opinions on what I saw. I am by no means an expert on any of these technologies but I do want to give you my first impressions of these from the perspective of a Software Developer and Architect working in the Enterprise IT space.
Spring Framework 3.0
One of the main focuses of the conference was the upcoming Spring Framework 3.0 release. Beyond just the framework itself, many of the other technologies leveraged some of the new 3.0 features. RC2 of the release should be available shortly. I would like to touch a bit on the feature set and particularly what excites me.
-
Spring Expression Language (SpEL) – This is one of the coolest new parts to the framework. A new expression language can be used to evaluate expressions related to other beans. In simple cases you can use something like #{refBean.value} in either the value attribute on a property or in the annotation directly. More complex expressions are also supported. This will be able to simplify configuration a great deal.
-
@Configuration – This is a rework of the Spring JavaConfig project that allows you to write your spring configurations in Java code directly. This project is now merged into the Spring framework 3.0. This feature did not excite me a whole lot. It seemed like something ‘cool’ but not something I would likely use. The main benefits of using this over XML were explained to be for refactoring, strong typing and losing the verbosity of XML. The refactoring and strong typing is less of an issue if you are using the Spring IDE (or STS) since it does all of that for you and even shows you where errors are. As for the syntax, I found the @Configuration to be clunky and still pretty verbose. If I wanted to express beans in code that are more readable, I would just use the Grails SpringBeanBuilder.
-
Java 5+ – Spring Framework 3.0 will be Java 5 and higher only. This is a great thing because it means that the core framework will fully support generics. All of the core libraries have been updated for this. In the past I stayed away from the JpaTemplate and other Spring libraries because the lack of generics made them more verbose than what I could write in wrappers of my own.
-
Task Executors – All of the scheduling stuff and executors were refactored. The Java 5 until.concurrent package is now used instead of the spring wrappers that they had. Also, scheduling is supported as part of Spring now. So for simple scheduling jobs (including cron), only spring will be required. This is nice since it is a common thing that is needed and Quartz is pretty heavy for this simple feature.
-
Rest Support – Spring Framework MVC now supports Rest. If you are an Spring MVC developer, this is very nice since you will be able to do REST directly from a @Controller method. If you are not using Spring MVC, there is no reason to look into this. The JAX-RS (JSR-311) spec is the way all of the other Java REST frameworks are going. I don’t see any reason to use this custom syntax over the standard for Rest unless you are using Spring MVC.
-
OXM – The Spring WS project created a bunch of stuff for handling Object to XML Mapping (OXM). Basically this is ORM for XML instead of a database. JAXB is one of the most popular frameworks for this and it is built in to the JVM. The OXM from Spring WS is now part of the core framework and allows anyone to have a single binding interface that can delegate to anyone of the many OXM frameworks out there including JAXB, XmlBeans, JiBX and Castor. This would be very nice for someone who wanted to support many different binding types but didn’t want to have to write all of that from scratch. On a whole the Spring Framework 3.0 release looks solid. I am going to have to grab the RC and check it out.
Spring Roo
Spring Roo was one of the technologies being shown at the conference. I had heard of it before but did not really do much digging into what it was. In a nutshell, it is a coding by convention framework for building applications (mostly web) in Java. Similar to Rails or Grails, it provides a console based utility to create entity beans (model), controllers and views. Instead of taking the dynamic language approach, Aspect J is used to merge common tools and scaffolding into the Java beans you create. It is a very cool product especially if you don’t have the luxury of using dynamic languages.
One of the more impressive aspects of this was the console they created. The console was intelligent and had full auto-complete support. I would like to see other console based applications use this type of thing in the future.
I played around with this a bit. It worked well for what it did. It will likely be used mostly for rapid prototyping. I think if I had to do a new web project, I would probably just do it in grails since I am already comfortable with Groovy. This would be great for people learning Java or with a need to rapidly prototype something in Java using Spring. Also, it saves the hassle of setting up things like JPA and MVC. Once the scaffolding is in place, you can customize it how you need.
SpringSource Tool Suite 2.2 (STS for short)
The SpringSource Tool Suite is an eclipse based development environment for all things Spring. It includes the old Spring IDE capabilities for editing spring XML files, support for Spring Roo, Groovy, Grails and Maven. The whole package works very well (except for the fact that the 2.2 release did not include the groovy plugin).
Not much is really new here. I had been using the Spring IDE and Groovy plugins already. Most of the components are available standalone. This will be very useful for people who don’t have any of these plugins and provides a single download.
The main focus of the IDE was centered around delpoying to dm Server and tc Server, both of which are included. The new Groovy plugin is great and has greatly improved over the last little while. It is available standalone which is probably how I will use it for now as I don’t have a need for many of the other features at this time.
Spring Integration
Spring Integration is like an ESB inside a single JVM. It seemed like a good project if you had a need for this type of thing. For me, I see the crossing JVM boundaries (clustering) one of the most important aspects of an ESB and this does nothing to tackle that problem. The samples that were presented showed how the integration could be done with OSGi. The capabilities were there but the configurations were very verbose and required writing some code in places for filters and other such things. I kept thinking how much easier it would be to just do these things in code directly and they would be a whole lot simpler. Thread Pools are so much easier now with Java’s util.concurrent and dynamic languages do routing really well. Both of those I am comfortable with. I think this project still has a long way to go before it can truly compete with an ESB type product.
Spring Batch
Spring Batch was shown alongside Spring Integration for handling large batch operations. The framework looked good and provided a lot of monitor capabilities around the status of the batches.
SpringSource tc Server
tc Server is SpringSource’s enterprise version of Tomcat. Essentially they took standard Tomcat and wrapped it with better monitoring and clustered deployment capabilities. This looks like a great solution for services type companies who want to deploy to a more enterprise version of Tomcat. For a products company though, it may be more difficult to manage since it is a commercial product. Most customers I have encountered either want to use their millions of dollars JEE environment or expect you to provide your own.
SpringSource tc Server Developer Edition
The Developer Edition of tc Server was announced at this conference. The main feature included here was called Spring Insight. This is a very cool tool targeted at application developers. It provides real time monitoring of an application that gives developers information about what is going on in the application. It includes health information, performance and the ability to drill down on web requests to see each call. Even SQL queries being run are shown from this console.
Everything is done through AOP runtime weaving so no code changes are required to run in this environment. Also, having this free for developers means developers will have a great environment for analyzing the performance of their applications. This is definitely something to check out for anyone who has a .war application.
SpringSource dm Server
SpringSource dm Server is Spring’s OSGi server. Similar to tc Server, this is an enterprise grade OSGi Server. They provide a lot of features to make OSGi easier including being able to deploy a standard .war file to the server and have it run.
OSGi is ready for prime time and has proven to be. It is definitely not one size fits all though. It is not something you just use because you can or because it is cool. The demos of dm Server and OSGi with Spring with littered with caveats and workarounds. OSGi is a great platform but still has a lot of pitfalls for application developers. Yes it has some cool things you can do with dependencies and versioning but they are not free.
Grails
I did not get into any of the Grails sessions. There were too many sessions I wanted to attend and I have already had some exposure to Grails so I stayed away from these for the most part. On a whole, it seems like Grails has come a long way from a competitive web framework to one of the best ones out there. If I had a new web application project to do, I would be most likely to choose Grails to do it in.
Griffon
Griffon is one of the newer Groovy frameworks to come out. It provides a Coding by Convention framework for Swing development and is targeted for developing Rich Internet Applications. The core is based on the Grails and will likely be familiar for those who already have Grails projects. The framework is built around making MVC easy through Swing and use of data binding. I am really looking forward to digging into this more.
The biggest hurdle I see is being able to leverage this technology in an existing application. One of our main products is a very large Swing based IDE. The code has been around for a long time and could benefit from newer patterns for GUI development. I would love to be able to integrate Griffon into it but at this time it may not be easy. I intend to look into this more to see if it is possible.
Groovy
This groovy language has also come a long way. I started using it when 1.0 was released. Since then it has really grown in capabilities. I learned a few tricks this time that I was not aware of. Most of them had to do with the annotations that were added in 1.6.
The biggest thing for Groovy though was the IDE support. I love the groovy language but have found that I could write Java faster in many circumstances even though I write more than twice the amount of code. The reason is because of the IDE support. Code Completion, Import completion and Refactoring are huge. The new Groovy plugin for eclipse is fantastic and includes all of these. Finally, I feel I can switch to using Groovy as my primary development language on the JVM. This is also a big step toward convincing others of the benefits of Groovy.