In this interview, Rod Johnson talks about the Spring framework, its positioning and how its dependency injection compares to that of Hivemind and PicoContainer. He looks at what's different in the Spring Petstore, how Spring ties into Hibernate and how scripting might fit into Spring. Rod also gives his thoughts on AOP standardization, TDD, and talks about his new book, 'J2EE without EJB'.

Rod Johnson on what's upcoming in 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."

Watch Rod Johnson's Interview

Interesting interview, especially on future plans. However, it would be nice to hear about Rod's thoughts on EJB 3. The spec takes on many of the IOC/Dependency Injection concepts facilitated by Spring and its "competitors", so surely closes the gap somewhat.

So does Spring IOC still add enough value to justify substituting - or building on top of - the soon-to-be industry standard IOC, thus adding an extra layer of complexity and adding to a typical project's learning curve? For Spring and others to be taken on in light of EJB 3, they will need to be able to justify that the value-add is substantial.

for every time getting more and more complicated and error prone.

With EJB 3.0 there is even more reason to use Spring. They had the chance to make a whole new concept, calling it something new and fresh, a new start!leaving the EJB Zombies from Night of The Living Dead to its destiny.

But no, the "new" EJB will still maintain all backwards compability to shoot itself in the foot being kept alive long after they should be dead and buried.

Is the J2EE vendors that much desperate?
Millions of lines of dead weight :(

"How much can a being mutate before it wants to die?"
The EJB 3.0 spec reminds me of is the old american cars in Cuba.

Regards
Rolf Tollerud

Container and Spring are two very different things and they do not conflict.
Spring is application development framework, j2ee container is a container for applications and services, but EJB tries to be standard application development framework too. I think this is the main EJB problem, there is no the best framework for all use cases and it can not be stable, I do not believe it can be possible to invent stable,standard framework. It is like art or fation and it can die or become obsolete at any time like SQLj, EJB, CCM, ... .

BTW add .NET and OLE to this list too.

Rolf,

> But no, the "new" EJB will still maintain all backwards compability to
> shoot itself in the foot being kept alive long after they should be dead
> and buried.

Err, what then would the options be for existing applications built using the
EJB 1.1 and 2.x specifications?

Backwards compatibility is important to customers. An answer from a J2EE
Application Server vendor along the lines of "Yes, when our product supports
spec version x, you either have to migrate (months/years of effort?) - or
continue using an older version of our product" is wholly unacceptable.

IMO, it is very reasonable for an AppServer to continue to support applications
built on existing/older specs while allowing side-by-side deployments on newer
versions of the specs. As an example - I could state some of the new features
introduced in the J2SE 1.5 (or 5.x). The intentions is that the bytecode
produced say, by using generics/auto-boxing will still continue to work on
older VMs. Would that decision by Sun to have backwards compatibility also
consitute a "shooting oneself in the foot"?

-krish

Please explain how the ability to treat POJOs as first class citizen would break backwards compability when no one is proposing to remove the old 2.x EJB. New functionality with a new cool name is the way to go.

Anyway I doubt that even that would help. Spring is like a empty rack only, where you can insert and remove "black boxes" at will, with an amazingly compact implementation. That is an unbeatable concept.

Regards
Rolf Tollerud

with an amazingly compact implementation. That is an unbeatable concept.RegardsRolf Tollerud

Actually Picocontainer beats it in terms of compactness. Picocontainer is about 50k wheras Spring is over 900k. Then again, you get a helluvalot more with Spring. :D

with an amazingly compact implementation. That is an unbeatable concept.RegardsRolf Tollerud

Actually Picocontainer beats it in terms of compactness. Picocontainer is about 50k wheras Spring is over 900k. Then again, you get a helluvalot more with Spring. :D

As you mention, that is for Spring with all functionality, including many aspects outside of the core container. Spring does also ship packaged by individual areas. spring-core.jar, for example, is currently only 225k for the CVS version, probably a bit less for the current 1.0.2...

Regards,
Colin

IMO, it is very reasonable for an AppServer to continue to support applications built on existing/older specs

Of course, but there is a rather large distinction between application servers supporting each of the different EJB specifications and having the specifications mandate this backwards compatibility.

Given the fundemental changes that are occuring in EJB 3.0 it is reasonable that a new generation of application servers may emerge, but to be considered 'compliant' they would have to support previous versions of the specifications. By the time we get into 4.0 or 5.0 it will be practically impossible for a new application server to enter the market. This would be unfortunate.

IMHO, Sun should release the specifications as distinct and let the vendors decide which specs to support. It is not the specification author's responsibility to ensure that the app server vendors can continue to support their existing clients.

IMHO, Sun should release the specifications as distinct and let the vendors decide which specs to support. It is not the specification author's responsibility to ensure that the app server vendors can continue to support their existing clients.

+1
User decides, hi needs this stuff or not and hi pays for everything,
clever vendors work for user, not for specification.

Backwards compatibility is important to customers.

It's hard for a Microsoft zealot to understand this, they don't have such a thing in their world...

That seems like a good opportunity for me to highlight some positive sides of Spring :-)
I am pretty sure that value proposition of lightweight containers (as we understand them right now), and specifically Spring as probably the best known open source lightweight container, will remain clear and will actually grow with introduction of EJB 3. The fundamental promise of lightweight containers is to go beyond J2EE and .NET functionality, and go there in multiple directions: simplification of often used APIs, providing functionality that is not available from specs, providing improved usability patterns for existing APIs, etc. In my opinion, the introduction of EJB3 (or J2EE 1.4), .NET 2.0 or any other technologies would not change the underlying “formula” behind lightweight containers (again, as a current collective term for frameworks like Spring); these frameworks will promptly adopt and grow to continuously provide substantial added value to a verity of J2EE/.NET based projects.

Regards,
Nikita Ivanov.

Michael, you might want to read my posting from another recent TSS thread on Spring and EJB 3:
http://theserverside.com/news/thread.tss?thread_id=27104#128843

As I elaborated there, Spring's scope is significantly wider than EJB 3's. Spring addresses logical reuse of business logic in any environment (J2EE server, Tomcat, standalone application, test suite, etc), also being able to provide its container services like dependency injection and declarative transactions in any such environment (in contrast to EJB 3).

Of course, Spring can also nicely be used for accessing or implementing EJBs. This is already the case with EJB 2.x; this will still be the case with EJB 3. Spring typically manages fine-granular application objects there, while EJBs are just used as facades (for example, remote entry points). Spring provides explicit EJB support classes for this usage style.

Juergen

"Spring's scope is significantly wider than EJB 3's"
As I understand spring provides/implements no services and is wrapper for j2ee services and it is more design pattern than container, why it can not be a wrapper for EJB 3 too ?

"Spring's scope is significantly wider than EJB 3's"As I understand spring provides/implements no services and is wrapper for j2ee services and it is more design pattern than container, why it can not be a wrapper for EJB 3 too ?

Sure, you can access EJB3s easily from a Spring context; Spring can provide the same means of access there as for current EJBs. For example, Spring can host the local middle tier of a web application within a WAR, linking in EJB3 facades from a (local or remote) EJB tier to delegate to.

The EJB3 EntityManager will also nicely integrate with Spring's DAO abstraction. Effectively, EJB3 entity beans will simply be one more option alongside the other data access strategies that Spring supports (JDBC, Hibernate, JDO, OJB, iBATIS SQL Maps).

What I meant regarding scope is that EJB still focuses on a component model for use within an EJB container, while Spring does not impose any restrictions in terms of target environments. In that respect, the scope of Spring IoC is significantly wider: It allows you to host components in any environment.

Beyond the target environment issue, Spring also provides much more sophisticated means for dependency injection, and lots of functionality completely beyond the scope of the EJB spec. EJB 3's IoC capability for Session Beans is effectively a small subset of Spring's IoC features.

Juergen

Sure, you can access EJB3s easily from a Spring context; Spring can provide the same means of access there as for current EJBs. For example, Spring can host the local middle tier of a web application within a WAR, linking in EJB3 facades from a (local or remote) EJB tier to delegate to.The EJB3 EntityManager will also nicely integrate with Spring's DAO abstraction. Effectively, EJB3 entity beans will simply be one more option alongside the other data access strategies that Spring supports (JDBC, Hibernate, JDO, OJB, iBATIS SQL Maps).

I see we started to talk about data access not about persistence :) I am sure all strategies are equal for data access code and all can be generated (DAO), it needs some metadata like "query string", but if you use DAO then you do not need nothing more than code generator and metadata. It is very trivial to generate all DAO's from iBATIS xml files, is not it ?
SQLj was the same idea, but it is dead for some reason, probably it is to "compex" :)

blockquote>SQLj was the same idea, but it is dead for some reason, probably it is to "compex" :)SQLJ is not dead. It is used a lot in mainframe environments. We're using it in a project which uses DB2 on z/OS. Moving from plain JDBC to SQLJ gave us a big performance improvement.

The WebSphere Studio (WSAD) development environment from IBM has build in support for SQLJ. It would be great if other development tools like Ant and frameworks like Spring and iBATIS supported SQLJ.

SQLJ does appear to be dead, as far as Oracle are concerned: JDBC and SQLJ:

"Starting with Oracle Database 10g, we are desupporting the SQLJ translator... We will shortly provide (and post here) a utility to ease the migration of SQLJ applications to pure JDBC applications."

From time to time I actually considered Spring support for SQLJ, and even considered using SQLJ for a current client project (on Oracle), but this finding this ruled it out.

R

I think it was not so bad idea, but problem is preprocessor, it generates unreadable code and breaks error diagnostic. Data access languages like plsql are better, but for data access only. I hope to "sell" SQLJ idea again and to use embedded SQL in anotations. SQL or procedure maps very good to DAO method and as I undersnad most developers use DAO with all persistence frameworks, I see no meaning for persistence if it is converted to data access again. Data access method can do more than SQL execution it is a very good subject for AOP.


It can be implemented manualy:

@Query "SELECT * FROM MY_TABLE WHERE id = $1"

SomeResult findById(int id){

    ResultSet rs = getResultSet();
     while(rs.next()){
       //process it
       ......
     }

}

Simple method can be abstract too:

@Query "SELECT * FROM MY_TABLE WHERE id = $1"
@Callback SomeResultCopier.class

abstract SomeResult findById(int id);


Add more anatotions like @Role,@Validate,@Log and it will be complete solution for enterprise application and it will be *declarative*.

Juozas,

Code generation for DAOs is IMO more or less unnecessary if you use a good data access library :-) For example, the following are complete data access operations that are coded with Spring's data access helpers:

  public void clearDatabase() throws DataAccessException {
    getJdbcTemplate().update("DELETE FROM imagedb");
  }

  public void deleteImage(int imageId) throws DataAccessException {
    getJdbcTemplate().update("DELETE FROM imagedb WHERE id=?", new Object[] {new Integer(imageId)});
  }

  public int getNrOfImages() throws DataAccessException {
    getJdbcTemplate().queryForInt("SELECT COUNT(*) FROM imagedb");
  }

  public List getImages() throws DataAccessException {
    return getJdbcTemplate().query(
        "SELECT image_name, description FROM imagedb",
        new RowMapperResultReader(new RowMapper() {
          public Object mapRow(ResultSet rs, int rowNum) throws SQLException {
            String name = rs.getString(1);
            String description = rs.getString(2);
            return new ImageDescriptor(name, description);
          }
        }));
    }
  }

As a detail, RowMapper implementations are thread-safe: They can thus also be kept as member objects of the DAO class, to be passed into a new RowMapperResultReader for each operation.

Note that there will be proper resource management, transaction participation, and translation of exceptions to Spring's generic DataAccessException hierarchy. The DAO implementation does not have to worry about any of those.

All you need to pass to the thread-safe JdbcTemplate instance used in this DAO is a javax.sql.DataSource to retrieve Connections from. Typically, this comes in via a setDataSource method or a constructor argument of type DataSource.

Similarly concise data access operations can be achieved for Hibernate, JDO, OJB and iBATIS SQL Maps, via Spring's corresponding template classes. For example, with Hibernate:

  public Collection findOwners(String lastName) throws DataAccessException {
    return getHibernateTemplate().find("from Owner owner where owner.lastName like ?", lastName + "%");
  }

  public Owner loadOwner(int id) throws DataAccessException {
    return (Owner) getHibernateTemplate().load(Owner.class, new Integer(id));
  }

  public void storeOwner(Owner owner) throws DataAccessException {
    getHibernateTemplate().saveOrUpdate(owner);
  }

Juergen

Juozai,

You can use Xdoclet hibernate tags and use hibernate named queries to get somewhat declarative data access. There's also a notion of named native SQL queries in hibernate you can define as metadata.

No, there is a very big difference. Probably it is not very clear from my posts, but idea is drop code and metadata (no generated files) and to maintain declaration only. Prototype works vey good for me (It is implemented with javadoc tags too). AOP helps to implement declerative cache, collect statistics. I have everyting I need for data access, I use the same decleration for query validation and automated tests, I have qery palans and statistics for performance tuning. Everything is related to code, I click on method declaration in UI and I see cache hit rate, query plan, SQL. This way scales very good and it is thread safe, there is no local cache and it has no problems with results of any size.
I understand, this way can not become more popular than O/R at this time, but I think it is EJB 4 :)

BTW I have tried the same with JTA and RPC (not for production at this time), it must work as WS without any coding and problems too (The same declaration is reused, protocol is a configuration parameter), but do not have use cases for WS at this time.

SQLJ does appear to be dead, as far as Oracle are concerned: JDBC and SQLJ:"Starting with Oracle Database 10g, we are desupporting the SQLJ translator... We will shortly provide (and post here) a utility to ease the migration of SQLJ applications to pure JDBC applications."From time to time I actually considered Spring support for SQLJ, and even considered using SQLJ for a current client project (on Oracle), but this finding this ruled it out.R

Rod, this is interesting. Look at that link again, it appears that there was enough industry inertia that Oracle reversed their decision! This is a strong sign that SQLJ is still very much alive in many environments!

JDBC and SQLJ

Rod,

JDBC and SQLJ:

The initial motivation for desupporting SQLJ was it's low adoption by the J2EE commnity however, we found out that it has been largely adopted by database developers. Following numerous complaints, and listening to his customers, Oracle has reverted the SQLJ Desupport decision; we have cancelled the Metalink Desupport Notice. Starting with Oracle Database 10g 10.1.0.4 patch set release, the SQLJ translator will be re-enabled, again. In the mean time, customers have full access to SQLJ functionalities using -sqlj option of the new Oracle Database 10g JPublisher utility.

Too many changes since July 2004...

Many times I was forced to design huge frameworks using PL/SQL, Microsoft Embedded SQL, etc; it is impossible to have such intermediary layer as a Java code running in separate container...


What about javax.sql.rowset.CachedRowSet, will it die?

It appears in the same link you've provided, JDBC and SQLJ, that Oracle as reverted its decision to decommission support for SQLJ. So now may be an appropriate time to reconsider SQLJ support in Spring.

Michael

Interesting interview, especially on future plans. However, it would be nice to hear about Rod's thoughts on EJB 3. The spec takes on many of the IOC/Dependency Injection concepts facilitated by Spring and its "competitors", so surely closes the gap somewhat.So does Spring IOC still add enough value to justify substituting - or building on top of - the soon-to-be industry standard IOC, thus adding an extra layer of complexity and adding to a typical project's learning curve? For Spring and others to be taken on in light of EJB 3, they will need to be able to justify that the value-add is substantial.

Good question.

Firstly, it's important to differentiate between a component model that adds some limited Dependency Injection features to help simplify its programming model (EJB3) with a true IoC container (Spring, Pico, HiveMind etc.). EJB3 does not standardize a general Dependency Injection mechanism. It's mainly a way of getting rid of verbose JNDI lookups (judging by section 8.1.3, "Injection and Lookup"). This is worthwhile, but it provides only a small part of the benefits that can flow from Dependency Injection overall.

Spring does provide a general IoC mechanism, with both Setter and Constructor Injection, Method Injection (in Spring 1.1), and the ability to manage object graphs of POJOs. It's possible to differentiate between "singleton" objects (shared instance, as with JNDI) or "non-singleton" objects (instance created on reference), supporting more advanced scenarios. Not to mention support for lists, maps (even nested), property type conversion etc... There's a lot more to a true IoC container than the EJB3 subset.

The Spring IoC container is also highly extensible, with the FactoryBean concept etc. It also integrates with AOP (Spring's own AOP framework and, as an additional option, AspectJ in Spring 1.1), whereas EJB3 does not provide an open AOP model...

In short: EJB3 may "narrow the gap," but in terms of programming model, the gap is still very wide. And Spring 1.1 (due out next month) and subsequent Spring releases should widen it...

Secondly, the Spring IoC container, like Pico and co, is usable in a wider range of scenarios than I would expect an EJB container ever will. (I have heard the aim expressed of making the EJB container "ubiquitous". Maybe it will happen, but I doubt it.) An IoC container distinct from the EJB container can be used anywhere: not just in a J2EE context. (J2EE != Java.) For example, the Spring RCP (Rich Client project) is generating a lot of interest now, and we have some users using Spring IoC in applets and standalone non-J2EE Java applications. A consistent model across all those environments is valuable.

Thirdly, I think we have to be realistic about applying the word "soon" to EJB3. We're a long way from a Proposed Final Draft, let alone the completion of the JCP process and production-ready containers actually supporting EJB3. The market leader in the application server space is now WebSphere. WebSphere 6 will be released at the end of this year, and will support J2EE 1.4, not 1.5. Thus it's reasonable to assume that WebSphere will support EJB3 in late 2005. Obviously people can't migrate to a new app server version overnight, so we'll see the user base come over in 2006. (And I doubt those guys are going to switch to another server to get EJB3 quicker.) It's clear from presentations I've seen at IBM user groups that IBM are focusing on today's technology set (quite reasonably). Thus EJB3 is just not an option now, and won't be for a while.

Fourth, Spring does a lot of things EJB3 does not seek to address. If I were programming EJB3 now (if I could program it now), I would be likely to use Spring for true IoC capability, interception that can't be done with EJB, superior JDBC usability, client-side access to remote EJBs etc... So the two things are not mutually exclusive. A better EJB would be good, but it won't displace good J2EE frameworks.

So, I think the value add is very substantial.

Rgds,
Rod

J2EE Without EJB
Spring Framework

Don't forget the entertainment value of pitting JSR - the epitome of bureaucratic committee management against two super-gifted talents from the upper atmosphere of the world's programmer elite.

The world is such a boring place according to Schopenhauer so we are forced to take every opportunity to get some amusement.. :)

Let the fun begin!

Regards
Rolf Tollerud
(Wodehouse admirer)

I would love to know which TDD book gets mentioned by Rod in the interview. I've been looking for books on the topic for a longer time, but was unable to choose one yet..

Also, is there *any* possibility to receive the recent 'J2EE without EJB' book in PDF format? There are countries, where snail mail has some real serious difficulties, and an electronic format would be very much preferred.

Also, is there *any* possibility to receive the recent 'J2EE without EJB' book in PDF format? There are countries, where snail mail has some real serious difficulties, and an electronic format would be very much preferred.

The publisher are reluctant, and have had piracy problems in the past. I have raised the idea of a PDF with them, and will do so again.

Regarding TDD books--I liked Vincent Massol's JUnit book, and Rick Hightower's book. But ultimately I think you learn TDD by doing...

I would love to know which TDD book gets mentioned by Rod in the interview. I've been looking for books on the topic for a longer time, but was unable to choose one yet.

Not a book, but this "XP Episode" from Object Mentor is a very good introduction to the principles of TDD and working with JUnit (as well as pair programming, incidentally).

Yes, thanks for the link. I reference that in the testing chapter of J2EE without EJB.

Not strictly TDD, but the pragmatic bookshelf has an outstanding book called "Pragmatic Unit Testing (in Java with JUnit)". Very short, to the point. An outstanding read. Mock objects, strategies, etc. It's a good book in a good series.

http://www.pragmaticprogrammer.com/bookshelf/

Nice one. It would really be very very nice if one could purchase a pdf of Rod's book. The last time I tried to try to purchase a printed copy on-line, it tooks about 2 months to arrice.

Matt Raible's Spring Live is now available in early release at www.springlive.com.

Also, is there *any* possibility to receive the recent 'J2EE without EJB' book in PDF format? There are countries, where snail mail has some real serious difficulties, and an electronic format would be very much preferred.

E-Book version is available. Check this link: http://www.wiley.com/WileyCDA/WileyTitle/productCd-076457390X.html

It's not a Java focused book, but I do like Kent Beck's Test Driven Development by Example:
http://www.amazon.com/exec/obidos/tg/detail/-/0321146530/qid=1089310889/sr=1-1/ref=sr_1_1/103-4377248-6371804?v=glance&s=books
Kent is of course one of the originators of JUnit.

I think this is a great introduction to unit testing, for people that don't currently 'get it'. If somebody is already pretty familiar and comfortable with unit testing, they may be better off goinging with a Java oriented book that looks at some of the related tools, such as jMock/EasyMock, IDE support, etc.

Regards,
Colin

I just finished reading Rod's "Expert One-On-One J2EE Design And Development" for the first time. I'd heard it was excellent, but it exceeded my expectations. I'm poring through it more carefully a second time. If I'd read it two years ago my projects would have been the better for it.

Looking forward to "J2EE Without EJBs" now. I don't have an EJB ax to grind. But if this book is as good as "Expert" it'll be worth studying. Thanks - MOD

There are actually two fairly significant transcription errors in question 5. I have highlighted them with @@@ below. In each case, when Rod said 'setter' in the audio, the transcript says 'constructor'. This obviously makes the transcript not make any sense :-)

 
-----
One of the differences is that Spring IoC is not ideological. For example, the PicoContainer guys now have support for @@@constructor@@@ 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 @@@constructor@@@ 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.
-----

Regards,
Colin

Colin,

Thanks for pointing these out. The typos have been fixed.

Regards,
Nitin

Colin,Thanks for pointing these out. The typos have been fixed.Regards,Nitin

You may have one more..."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 setter injection."

Don't the Pico guys like constructor injection and the Spring guys setter?

In fixing the two typos, looks like I created two more. :)

Dave, you're right, the Pico guys prefer constructor injection and the Spring guys prefer setter injection.

Errata fixed.

-Nitin