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

Johnson: 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.

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

Johnson: 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.

InfoWorld: 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?