Spring Framework author offers Java outlook

InfoWorld - Rod Johnson, founder of the Spring Framework for Java, CEO of Interface21 and a consultant, holds a prominent status in the Java development community. He is also the author of Expert One-on-One J2EE Design and Development and Expert One-on-One J2EE Development without EJB. InfoWorld spoke with Johnson during TheServerSide Java Symposium in Las Vegas last week about 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 toward 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 and credit account, 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 and addresses. The problem of duplication becomes still worse.

Reprinted with permission from

For more enterprise computing news, visit Infoworld.com
Story copyright 2006 InfoWorld Media Group, Inc. All rights reserved.