Rod Johnson is the author of the best-selling "Expert One-on-One J2EE Design and Development" , "J2EE without EJB", and the founder of the Spring Framework. He is on the Servlet 2.4 and JDO 2.0 Expert Groups. Rod has been working with Java and J2EE since their release, consulting in the dotcom, insurance and finance industries.

Welcome, Rod, can you introduce yourself to the community again?

Traditionally, I've been a developer of business applications, which I've found to be probably the most important thing you need to do in order to understand the real needs of the community out there. I'm also the author of 'Expert One-on-One J2EE' which was published in late 2002, and also in the 'Expert One-On-One' series, 'J2EE without EJB', which will be published in May. I'm also the co-founder of the The Spring Framework, an open source project which grew out of my first book.

What are your thoughts on the take off of the lightweight container movement?

I think it's the most exciting thing happening in J2EE at the moment. I think it has tremendous implications for the whole of Java, not just J2EE. I think it was really the big story since the last ServerSide event. Back in Boston, at the first ServerSide event, we had made the first announcements about Spring which had already been in development for quite some time at that point. I first heard about PicoContainer and some of the other lightweight frameworks out there.

I think what we've seen in the last year is that technology maturing, actually going into production and producing a tremendous value to users. And I think EJB 3.0 is clearly moving in the right direction that shows that Sun recognizes the value of that approach and are effectively validating it.

What is Spring, and what's its positioning?

It is very difficult to come up with a snappy catch phrase for Spring, partly because Spring isn't about the Spring architecture or the Spring developers; Spring is about you, if you are a Spring user. Spring is a framework that aims to make doing what you want to do, easier to do. I know that sounds like 'Spring is the answer to all problems', and obviously, Spring is not the answer to all problems, but if you look at a lot of the things a typical J2EE developer needs to do to deliver real, working applications, Spring actually makes those things easy to do.

For example, if you need to access EJBs, Spring takes away all the pain of using JNDI. If you need to use JDBC, Spring takes away the 'try', 'catch', 'finally' blocks; Spring takes away the vendor-specific handling of exception error code.

The core of Spring is the Inversion of Control container and we consistently apply Inversion of Control and dependency injection throughout the framework itself. We aim, above everything else, to make Spring a non-invasive framework. Spring provides you with the ability to structure your objects as POJOs; your business objects will be POJOs. Ideally, they will not depend on Spring, or any other container APIs. Spring aims not only that you don't need to depend on J2EE APIs like JNDI or JTA, but you don't need to depend on Spring APIs, and that's where you get this synergy between Inversion of Control and AOP, where your code doesn't need to use Spring APIs, but it can benefit from Inversion of Control through dependency injection and can benefit from declarative services such as declarative transaction management.

What's different in the Spring PetStore?

The Spring PetStore owes a huge debt of gratitude to Clinton's oringla JPetStore. I think it's really important to make that point because we find people download the Spring PetStore and don't actually realize that Clinton did a lot of the heavy lifting there. The original IBatis JPetStore made tremendous improvements on the Sun Java PetStore. It was simple. It had a reasonable amount of code for what it did. It was maintainable.

The Spring JPetStore I believe, is another improvement, it's another shift forward. What it does is take an architecture which was absolutely fine in the original JPetStore for a small application, but it takes that to the next step where it uses an architecture which can be the basis for scaling up into a more complex application. So for example, in the IBatis JPetStore, there is signifcant use of the Singleton pattern, for wiring up the application. There is code that is not really concerned with the business operations. In the Spring JPetStore, there is not only nothing that depends on Spring, but there is none of that glue code.

We actually preserve the data access layer using Clinton's IBatis framework; we have integration for that. What we have done is abstracted the business objects from that data access technology but of course Clinton had already put in a pretty good DAO layer there.

We also provide both a Struts Web tier which works with Struts 1.1 and a Spring MVC Web tier so people can see the comparison.

How is Spring's dependency injection different from Hivemind and PicoContainer?

The first part of the answer is that it's not different, and that's great, because all those products are about enabling the use of POJOs that have no container dependencies and I mean there is no radical difference in model. They all take plain Java classes and satisfy their dependencies.

One of the differences is that Spring IoC is not ideological. For example, the PicoContainer guys now have support for setter injections and they do recognize you need support for both but they have a strong preference for constructor injection.

We take the view that the customer is always right. Personally, I do still prefer setter injection, but nevertheless, if you choose to use Spring, if you choose to use IoC, and you want to use constructor injection, I see it as our job to ensure that you can do that effectively.

One other nice thing about Spring IoC is that we have very good support for configuration properties, like simple types, and I think that's something some of the other frameworks don't handle quite as well. We have the integration with AOP features, it's seamless with Spring IoC, and also we have some pretty neat stuff around not just managing object dependencies and simple types but things like maps, lists, maps that contain entries that are lists of maps, I mean that's obviously a pretty weird and contrived example but it's really powerful especially if you have legacy code. Even if the dependencies are pretty complex, you can wire them up with Spring without making your application depend on Spring.

When you talk to developers who use dependency injection, a light seems to go on when they use IOC. Why is this?

Firstly because they realize how much work they were doing that they didn't need to do. If you use dependency injection appropriately, you eliminate a whole bunch of code. Certainly in the case of Spring and HiveMind, you're going to have some metadata as well as the code. But you find that the balance is really good; you have certain things in quite simple metadata but you have, overall, in terms of metadata in code, far less than in the traditional approach.

So the traditional approach to J2EE results in developers spending a significant part of their day debating whether they should use a Service Locator or a Business Delegate, coding it up, writing the singletons or custom factories. With IoC you simply don't need to do that, and it works. It's an almost scary idea in its simplicity. When I first started using that concept back in 2000 in a framework that I wrote for commercial client, I remember thinking, 'hey this is too simple, there's got to be something wrong here.' And obviously you need to provide sophisticated features; you do need to support callback intefaces under certain circumstances. I mean, dependency injection might not solve 100% of cases, but dependency injection might solve about 99% of cases in a beautifully elegant way.

What are your thoughts on Test Driven Development? Should you write tests first?

I think one of the most positive things in the show (TSSJS 2004), was Linda recognizing in the EJB 3.0 presentation, just how important TDD is. And I think we've now got to the crossover point where I've found over the last couple of years that it's getting easier and easier to sell TDD. Maybe 18 months ago, I was trying to push TDD in a banking environment and I was regarded as this kind of weirdo who's into all those way-out things. Wheras now I think there's recognition that this is totally mainstream. There's a fantastic book on TDD. It simply helps you deliver better software faster. I don't think I really need to sell the concept to TheServerSide audience. And I think any one of the real value propositions of the lightweight container, is that they enable you to practice TDD effectively.

Some people claim that it is a pro that you can plug in anything you want, others say it's confusing. What are your thoughts?

I think technically, our strategies are right. The question is, how this comes across to people; it can confuse them. I think it's important that you don't make people rip up their existing code. For example, you need to support people with a refactoring use of Spring, like how they've got a Struts Web tier, they've possibly implemented some value added features or using some open source plugins for Struts to do workflow or something. It is unreasonable to those people to say, 'hey, if you use Spring, we say you must use our MVC framework, you're either going to throw that away or redevelop it for Spring.

So I think it's important to have this approach where you can mix or match. So we very much have this approach that Spring is about best of breed solutions. So we keep that integration with different products from polluting the core and that is a very, very important point. If you look at the core dependencies of Spring, it's basically Commons logging or Log4J, if you want to use Log4J. So what the core dependencies of the Spring framework, even the AOP framework, are just the stuff that everyone already has on their classpath. What's important is that people realize is that you don't need every product under the Sun to use Spring effectively.

What are some of the ways in which you tie into Hibernate?

We aim to make Hibernate easy to use. So for example, we aim take away the needs for people to write their own custom implementations of ThreadLocalSessions which is very common with Hibernate. We integrate Hibernate into Springs transaction management abstraction. We intregrate with Spring's data access exception hierarchy. That is a very important concept because it means that your DAO's are truly agnostic of the technology.

Hibernate's a great product, but I prefer, ideally, not to work in the middle tier with the Hibernate APIs. And Spring provides a data access agnostic technology. For example, if I can implement my DAO's that throws a Spring data access exception hierarchy and I can deal with that, if I choose to, in the middle tier. So then, if I find I made a mistake using O/R mapping for a certain operation and I really need to use JDBC, just for that, I can switch, behind that DAO interface, to using Spring JDBC in all my exception handling code with calls that will still work.

We enable the use of Hibernate local transactions. Obviously it works with JCA as well, if people choose that. But if you just want to use, for example, a typical lightweight web architecture, that Spring and Hibernate may be running on Tomcat, you can have declarative transaction management with POJOs, with Hibernate, and you can even do JDBC operations within the same transaction.

In your projects do you find yourself moving towards Hibernate, or the Spring JDBC wrapper?

I don't think you can really compare the two. They certainly don't compete. I'd rephrase the question as O/R mapping or SQL-based, direct relational concepts. I would never use an O/R mapping solution where it didn't add value. I find that probably in 80% that I do, there's a real value proposition in O/R mapping. It makes my life as a developer a whole lot easier. And there are a lot of good products in that space: Hibernate is obviously an excellent product. A lot of our users use it happily. I also have a high opinion of the SolarMetric group and their JDO product. So there are a lot of good technologies there; I think much more mature than they used to be 2 or 3 years ago.

But on the other hand, for that other 20%, you really find that an O/R mapping framework like Hibernate will certainly let you issue SQL queries, but nevertheless, there are times for example, in the project I'm working on now, I need ultimate efficieny. I need to issue a million insert statements in one transaction, and I'm never going to read that data again, it's write only. That is the classic kind of thing where Spring gives you a very nice way of tapping into JDBC batch update support. And I've had to experiment with the configuration and I've discovered that the optimal batch size is 5000. So I'm not going to read that data again, so I'm not too bothered about writing the SQL to do the insert. Eventhough a very lightweight product like Hibernate will add a small overhead, I don't want even that small overhead in that application.

Have you noticed a difference in the market when you suggest Simple versus EJB?

I think it's incredible. It's happened in the last year. On the last project I worked on for much of last year, there was absolutely no prospect that they were going to reduce their overuse of EJB. In my current project, actually, one of the Managers who's not so technical, really didn't know the kinds of things I'm associated with in the J2EE community. He sat down with me and said he'd hope he'd see a lot fewer EJBs, in my design for the application.

That's not to say that nobody should use EJB, or that EJB is dying. I think what it means is that people are realizing, even people who are not necessarily technical, that this is a technology that is not always appropriate, and it's a complex technology and you need to think really carefully about what the value proposition is and why you're implementing something as an EJB rather than a POJO.

Spring has support for AOP. Where do you find yourself using it?

I guess like most Spring users, I most commonly use it for declarative transaction management and of course Spring makes that pretty simpleso you don't even need to know the fact that you're doing AOP. On a project of moderate size, I find I would probably end up writing 2 or 3 custom aspects. For example, on my current project, I've implemented a caching aspect. Obviously, using a product like Hibernate or Kodo, you get a good second level cache, but I have a really atypical requirement, in that the caching needs to be driven by, the sort of, business use of that data. The second level cache in the O/R mapper doesn't help. And my first thought on this was, 'well I'm not sure about adding this interception overhead, but maybe I should just try it with Spring AOP and put in a caching aspect'. I implemented the aspect in under an hour. I ran it and the performance was absolutely fine. If I had adopted a traditional approach to that, I would've had a classic cross-cutting concern; I would've been writing caching code in a whole bunch of methods. So if you hit the sweet spot, I think that AOP can deliver dramatic simplification.

Have you noticed any issues using AOP in the real world?

I can honestly say I haven't, but that's probably because I haven't worked on a project where AspectJ was being used or AspectWerkz. I mean, obviously, they give you significantly greater capabilities than Spring, a more lightweight AOP framework, and that's both good and bad. It's good because you can do all kind of cool things, and it's bad because you can do all kinds of cool things.

I have tended to see, in projects I've worked on, there tends to be differnet levels of developers in their confidence and interest in AOP. And that's healthy. That works just great. That's another way of modularizing who does what in a project, and I think AOP brings a real value in parceling outworking teams.

So, typically, what I will find is, everyone cottons on to the fact that if they want transaction management, declarative transaction management, if they're using Spring, works just great. Maybe 80% of the developers aren't interested in how that's implemented, but you'll certainly find a significant proportion, maybe 30 to 40% will be interested in how that works; they'll start looking at the underlying technology. And then you'll find that maybe 20% of the guys really take it to the next level; they think, what's all the pointcut, joinpoint stuff..they'll start reading up on AspectJ, they'll buy a book from Manning, written by Laddad, AOP with AspectJ, and I strongly recommend people take a look at that.

And then they start getting into writing custom aspects and that works really well because you get a minority of guys who are really up to speed with this technology who end up implementing aspects that the other developers end up benefiting with. And yet you don't end up with a bunch of people who really don't understand the concepts, experimenting in weird ways with aspects.

Where do you think we can standardize AOP?

I'm probably not the best person to answer that question. I'm very much in favour of standardization but I think it's been really encouraging to hear from Gregor Kiczales, the father of AOP, that he is going to be heading up a standardization push. So I will certainly be a part of that, but I think it's fantastic that Gregor's going to be driving it, and I think it will involve all of the key players.

What do you think of the state of pointcuts in AOP?

I think pointcuts are core to what AOP is. Certainly, there really isn't a lot of standardization in that space. There's a conceptual standardization, but there's no code standardization. We've got a degree of standardization in lightweight AOP frameworks with the AOP Alliance which Spring's and Bob Lee's DynaAOP both support. So that enables use of the Spring transaction interceptor in applications that use DynaAOP. But there's nothing similar with pointcuts at a code level; there's no code compatibility. The model is relatively similar, but you cannot reuse pointcuts. That may change with what we're looking at in th Spring 1.1 timeframe, at introducing an expression language and I know Bob's quite interested in seeing if we can do a joint effort on that. But hopefully, this is something that will be addressed by the initiative that I mentioned that Gregor Kiczales is heading up.

What do you see on the horizon for Spring 1.1 and future versions?

The feature set for Spring 1.1 is pretty much set now. We're looking at JMS support, which will be focused primarily around publishing messages very easily. We're also looking at dynamic reconfiguration features. For example, Spring may be able to pull configuration held in an XML file on the network or in the database and objects will be updatable in a threadsafe way. So for example, if object A depends on object B, you will actually be able to change in your definitions, the implementing class of object B, and yet the reference that A holds to B, will still be honoured. I think that's a really interesting feature. We're also looking at the pointcut expression language and some other AOP enhancements. We're looking at JSF integration . I think that will make 1.1 and possibly portlet integration.

Now, you talked about JMS support. What do you mean by JMS support? Are you referring to message driven beans?

Spring already provides support for implementing Message Driven Beans. Basically, MDBs are my favourite type of EJB. Spring doesn't aim to reinvent the wheel, so long as the wheel is perfectly round. MDBs are a good technology. They do what I want them to do; I actually use MDBs quite a bit. We're not aiming to provide a replacement for MDBs. We already make MDBs pretty easy to implement. We do want to go where the EJB spec doesn't go. The EJB spec doesn't help you publish messages. We're able to provide a very simple way of publishing messages.

What are your thoughts about scripting and how it can fit in with Spring?

There's clearly a huge amount of interest in scripting languages at the moment, I mean particularly Groovy seems to have gotten a lot of interest in the community. I'm very open to the value proposition of using scripting in Spring configuration because people often think that Spring is about XML configuration. Certainly, XML is the dominant medium that people use for configuration, and I think it works great. I think the Spring XML configuration syntax is not particularly verbose. I sit in Eclipse using XMLBuddy, and I never type any tags, I just get promptings from the DTD.

I think however, it is important that we continue to experiment and innovate in terms of how people define objects in Spring context, and we are doing some work at the moment on Groovy. I must say, personally, I don't see a compelling value proposition there, but I'm really trying. My mind is very open on this and there probably will be some support in the Spring 1.1 timeframe.

You mentioned that you're an MDB user. How do Spring and EJB fit together?

Firstly, Spring does not force you to throw out EJB. Spring makes it significantly easier both to implement and to use EJBs. For example, if I'm going to implement a stateless session bean, I would probably extend one off the Spring superclasses, which enables me to have a Spring lightweight container behind the EJB facade. That's perfectly legal in the EJB API, does not conflict with EJB in any way. I'm now using the EJB facade to give me things like the EJB transaction management, if that's what I wanted to do and potentially remoting, and I'm applying the strengths of EJB but I'm also enjoying the strengths of Spring because I've got all my objects nicely configured up; I don't have to mess with ad hoc environment variables, or lookups in my EJB.

Spring makes it significantly easier to access EJBs. Now if I'm writing code, say, in the Web tier that accesses that stateless session bean, in the old days, we'd have to write JNDI lookup code, Service Locater, something like that. With Spring, I don't. I will obviously follow best practices and have the business methods interface with my stateless session bean. I will actually write code in the client tier that will express a dependency on that business method's interface, which does not depend on the EJB API; so I will expose a setter method, set my business method's interface and populate it using Spring's dependency injection. There is no Java lookup code required

So Spring makes it a lot easier to use EJB but Spring obviously does give you a really good alternative to EJB in a large range or situations. With respect to MDBs as I mentioned earlier, we think MDBs are a pretty good technology and personally, I write quite a lot of MDBs. I'm working on a very intersting application at the moment where I'm using JMS to pass control over quite a large cluster. Every one of my MDBs is actually a facade, an entry point, and behind that there's a Spring context, and there's quite a rich object graph defined there.

Do you enjoy working with Spring as a user?

I really do and I mean, this isn't just marketing. I find that if I'm using Spring, I'm writing less code than I used to, I'm able to test my code really easily. The code that I write is completely relevant to the problem domain and I think that's fantastic. And I would now no longer consider developing a J2EE application without a lightweight container. I really think that Spring is the best product in that space, but if Spring didn't exist, I'd be using PicoContainer or HiveMind, there is no question about it.

What are you excited about in the Java community at the moment?

I think one of the most exciting new features are the language enhancements in J2SE 1.5. I will be absolutely delited when I no longer have to deal with untyped exceptions. I think the annotations stuff is pretty cool as well. I'm a little concerned that people may overuse it, but I still think there are areas like transaction management, you know transaction annotations are still a pretty obvious and elegant way to do things. I think 1.5 is a big new release of the language and I think that's great.

Rod, can you tell us a little about your new book, "J2EE Without EJB"?

'J2EE without EJB' is the sequel to 'Expert One-on-One J2EE'. It's very much in the same tradition of showing a practical approach that I've found, from experience, to work well. It's a book that I would describe partly as a lightweight container manifesto. It is not purely a Spring book. It has a lot of examples using Spring but it's basically an architecture book that talks about lightweight, efficient, productive ways to build J2EE applications. Actually, it's important to make the point that it's not a polemic. This is not a 500 page book of 'Rod Johnson hates EJB'.

Thanks for your time Rod, we look forward to seeing you at the next Symposium

Thanks very much Nitin. And I have to put in a plug for you guys. I really think that TheServerSide event in Vegas this year was the best technical event I've ever been to. Thank you.