Disclaimer: I am a co-author of the upcoming Manning book, Spring Roo in Action, and a consultant for Chariot Solutions, a SpringSource partner. That said, I'm normally not a cheerleader. These are my thoughts around the recent speech by Rod Johnson of SpringSource. - Ken Rimple
Rod Johnson spoke last Thursday at the Philadelphia area Java User Group. Although I got called away for a family matter at the end (darn!) I heard what I hoped to be the case: that VMWare has a strong interest in improving developer productivity, in general, for cloud computing and for mobile applications, and to that end, invested in SpringSource, which is also leading SpringSource to invest heavily in both Grails and Spring Roo.
I am a fan of both platforms. Grails, with the Groovy language, is one of the best things to happen to dynamic programming on the Java VM in a long time. With access to any Java library or framework, including the built-in Spring and Hibernate platforms, it gives new meaning to "Rapid Application Development."
Spring Roo, on the other hand, solves the productivity problem more unconventionally. Pop quiz: when you hear the words "Aspect-J" and "Rapid Application Development" together, does it make sense? Most people view Aspect-J as powerful and complicated. While this is generally somewhat undeserved, Aspect-J, applied too liberally, can make a mess of an otherwise well-organized project. Most junior to mid-level developers fail to grasp it, and senior developers usually apply it surgically to do some really great things. Spring, in fact, uses aspect-oriented programming behind the scenes, when it does things like write dynamic Java Proxies to handle transaction management and security.
Roo is different because it uses a new feature of Aspect-J : Inter-Type Declarations. Using Aspect-J class files, developers can weave features from various aspect files into a single class at compile time. For example, Spring Roo Entities are comprised of at least four different class fragments - the entity class itself, with the fields of the entity, the JavaBean file, which contains setters/getters, the configurable, which adds the @Configurable annotation, and the Entity Aspect, which contains all of the methods to persist, find, query and remove entities from the database.
Rod's statement about how the Java platform has a short period of time to really take over the cloud computing industry was interesting. He stated that Java developers are "really smart, and that's a good thing," and then something along the lines of, "The problem is that Java developers think they are really smart, which is a bad thing." Probably paraphrased wrong, but rather hilarious. He put a hypothetical scenario in front of us stating that, given a moderate problem to solve, a Java, Ruby and .NET developer would go about it different ways:
First, the Ruby developer would get done on time. The .NET developer would also finish, but the Java developer would have reviewed ALL OF THE OPTIONS and not necessarily have coded a single thing. He says that is our problem, and that there are so many choices (a point I've argued a lot) that it makes it difficult for us to make decisions. I've seen a great talk by Scott Davis years ago that mentioned the "tyranny of choice" - when our combinations of choices go up, we begin to 'vapor lock' and paralyze ourselves with decisions. BTW because of Scott (and also Andy Hunt) there is a book on my reading list, "The Paradox of Choice."
So, we on Java have to get more rapid in our application development. And hopefully, that's where Spring Roo leads us. I developed on PowerBuilder back in the 90's for five years. Why? Because the alternatives for building business applications weren't so good: VB 2.0? terrible. FoxPro? What? C++? Come on! And then entered the web and Java, and we've been on the complexity train for a long time. Spring has done a ton to make this easier, but we have to do better. We must get to the point where it becomes trivial to boot up an application platform, to add persistence to our applications, to write a web application, to send emails, etc... Grails and Roo should get us closer to that goal.
I left at the point where Rod was laying out the mobile strategy. However, I see that Roo just got updated to 1.1.0.M1, which contains the starting point for building GWT applications (as well as Google App Engine back-ends). It certainly looks promising for the 1.1.0 GA release. But at least I think I've put decent bets on two good horses for rapid development on the Java platform with Grails and Roo.
Here's to what looks like an interesting 6-12 months on the Java platform.