State of Java perspectives offered by Spring Framework author

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.

Free IT resource Open Source Business Conference (OSBC) May 22-23, 2007 Sponsored by OSBC Free IT resource Virtualization Insights from Top Experts - Learn how virtualization gets real! Sponsored by Dell

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.