Rod Johnson holds a prominent status in the Java development community. He is the founder of the Spring Framework for Java, a consultant and author. He wrote the books, Expert One-on-One J2EE Design and Development and Expert One-on-One J2EE Development without EJB. He also is CEO of Interface21, an international consulting firm. InfoWorld Editor at Large Paul Krill spoke with Johnson during TheServerSide Java Symposium in Las Vegas last week about topics such as simplifying and open sourcing Java, aspect-oriented programming, the Spring Framework, and how .Net stacks up as a competitor to Java.

What obstacles do you see to simplifying Java programming and how much simplification does it need?

In terms of simplification, I think the Java language itself did a pretty good job of simplifying a lot of constructs, certainly compared to the history behind it with C++. And I think that [with] Java 5, the language level continues that. In terms of where we find the greatest complexity, it's really in the area of server-side Java, and I think we've made huge progress in the last few years towards POJO-based (Plain Old Java Objects) development. I think that certainly the reality is server-side Java development today is much simpler than it was with the original J2EE model.

What are the main benefits of aspect-oriented programming and why should developers hop on the bandwagon if they haven't already done so?

The main benefit of aspect-oriented programming is that it complements object-oriented programming. Object-oriented programming has spread into a very, very successful paradigm, and one of the great things about it is the way in which it helps you foster reuse and remove duplication. So, for example, if you have an account class and you [extend] from that savings account, checking account, credit account, etc., you have a very nice way of using that hierarchy to encapsulate logic that you want to reuse. Where it does, fall down, however, [is] in addressing what we call crosscutting concerns. Crosscutting concerns are pieces of functionality that may apply to a whole system that would, if they're implemented in the traditional object-oriented way, affect multiple classes and methods. Let's take, as an example, the notion of auditing. There is, of course, the ability to have helper functionality in a base class, like a base account class, that will, for example, run auditing behavior. But what happens if we say that every method that can lead to a change in the state of the savings account should be audited? There is no way in classic OO-modeling to avoid duplication in doing that. You will end up with the auditing code scattered between multiple methods. And of course it gets much worse when you say that auditing should apply to savings accounts, that it also should apply to different areas of functionality, such as inventories, addresses, etc. The problem of duplication becomes still worse. So aspect-oriented programming introduces the concept of an aspect. An aspect really is a way of modularizing the code that will apply a crosscutting concern. [With] the Spring Framework, the transaction management and security are delivered by an aspect approach, so users are not necessarily forced to explicitly work with OOP constructs, but they nevertheless benefit from this modularization of code that would otherwise be scattered.

Explain your role in the development of the Spring Framework. And could you briefly compare Spring to other frameworks, such as JavaServer Faces and WebWork?

The Spring Framework grew out of my first book on J2EE, Expert One-on-One J2EE Design and Development, which was published in late-2002. That book really helped to start what we might call the lightweight revolution in J2EE. It really argued that the traditional model was way too complex, and with the book I actually published 30,000 lines of code, which was originally intended to show my view on how things could be done in a simpler way through an application framework. But of course, many readers became very interested in this and quickly I was persuaded to make it an open-source project. So development started in earnest in early-2003. Compared to other frameworks, Spring really created a niche for itself. So Spring is what we call an application framework, and it actually addresses multiple architectural tiers. So if you look at frameworks [such as] Struts or WebWork, they more often than not just address one architectural layer. So Struts and WebWork are both Web frameworks. Compared to JSF, Spring and JSF are not really in the same space. JSF is essentially a component model for rendering Web resources, whereas Spring is more a framework that aims to bring an overall structure and coherency to your application as a whole. So Spring actually can be used with JSF. Spring does provide its own MVC (Model-View Controller) Web framework, which I guess can be regarded as being in the same space as Struts and WebWork, but on the other hand, Spring is a modular framework.

You once said the Java Community Process reminds you of an old Soviet-style planned economy. Could you elaborate on that?

I think [it was in] the traditional approach, and in fairness to the JCP, I think this has begun to change now. But the traditional approach involved a committee, which was more often than not dominated by vendors, defining essentially the programming model. The problem with this approach was that it really wasn't based on either competition or experience. So more often than not, you [found that] really quite complex programming models, such as the original EJB (Enterprise JavaBeans) programming model, were defined by groups of people who did not actually develop applications. So they developed servers. They were highly skilled and highly intelligent people, but that's not the same thing as being regularly exposed to what people were doing in banks and all the real businesses that actually used this software. So the reason that I referred to the notion of capitalism versus the Soviet system is that the effect of this was that there was something that was mandated. This was the way you were going to do it for the next few years. And it meant that if the approach was not a good approach, it would actually survive for a long time. And it also meant that there wasn't that much opportunity for the kind of innovation that we see, for example, in business or where you get a lot of competition forcing people to [lift] their [game] and innovate.