JavaOne Day Three

I'll keep this pretty short for now, since the Wi-Fi is definitely not holding up as well today as it did earlier in the week!

I went to two sessions this morning. The first was on Web Beans. Gavin King did a great job explaining the ideas and the possibilities created by Web Beans. Bob Lee added some bits on some of the things in Guice that will make it into Web Beans. You can tell things are at an early stage, and it's hard to know if Web Beans will just be a superset of Seam and Guice. From my perspective, Seam is more powerful, but Guice is more elegant. Two interesting questions in the Q&A. First, somebody asked about involvement by the Spring guys on Web Beans. Bob Lee says they have been invited to the expert group, but so far no interest. There's a lot you can imply about that, enough for another post some other time. Next, somebody asked about the compatibility between Web Beans and the component model for the Service Component Architecture JSR. Gavin King balked at this, as seemed to think the whole notion of Service Component was a contradiction of terms. He said he couldn't say much more without being extremely negative.

Next session was Effective Java Reloaded by the venerable Joshua Bloch. First surprising thing was that Bloch is the "Chief Java Architect" at Google. And I thought they didn't have titles at Google and everybody was a software engineer! His talk was great. He had some really cool things with generics in particular. He talked about the SuperType Tokens that I had fist read about in Bob Lee's blog last year. It was a very useful talk. The only disappointing part is that he told us that book by the same title (the sequel to his successful Effective Java) won't be ready until the end of the year. I don't buy too many Java books anymore, but that's definitely one I will buy.

Guice, Spring, and Arid

I was reading this article on Arid POJOs on TSS today. Chris Richardson, the author of Arid, has a nice introduction to it. One thing I found amusing was the statement at the beginning

...an important benefit of using XML is that it completely decouples the components that are being assembled from the mechanism that is assembling them This is not true when using annotation-based dependency injection such as that provided by the Guice framework. Components that use those kinds of annotations are tightly coupled to the framework and are definitely not POJOs!

I've been known to make my own digs on Google frameworks, but sometimes you have to call out FUD when you see it. The POJO argument usually comes from the requirements of writing EJBs prior to EJB3. You had a lot of interfaces to implement, and some of these interfaces required a lot of methods (typically lifecycle callback methods) to implement. To be an EJB you had to look like an EJB to the container, hence all those interfaces and methods to implement. The term POJO came about because POJOs don't look like EJBs.

So it is ridiculous to somehow say that a class that uses a com.google.inject (or javax.ejb for that matter) Annotation is not a POJO. Can a POJO not have any Annotations? Can a POJO not reference third party packages? Better remove all your Jakarta commons import statements...

As for tightly coupling to a framework, I will concede that it is nice to be able to switch out your DI provider without having to change code. I guess that is one drawback of using Guice. The Guice solution of writing a Module class for doing all the wiring and thus isolate the dependency doesn't seem realistic. You could do the same thing in Spring: programmatically create your configuration and thus wire together your classes. Nobody does that though, they all use XML files or maybe auto-wiring.

So maybe Chris Richardson has a valid point here. Bob Lee and the Guice gang at Google make some strong arguments for switching to Guice from Spring. You have to change code to make that switch, and you'd have to change code again to switch back.

I think in many cases, it is worth the "pollution" of your code. The thing I like about EJB3 and Guice annotations is the explicit dependencies. I have to worry about not only writing code, but also about writing code that other developers can understand. I have to worry about the learning curve I create for new developers I hire. There is a lot of clarity in something like:

@ImplementedBy(MyClassImpl.class)
public interface MyClass { ... }

There is also a lot of clarity in seeing a unit test that creates a module to override the bindings to allow for mock versions of certain classes.

At Ludi Labs, we used Spring in just about every way it can be used. Sometimes we got a little carried away and patted ourselves on the back about how clever we were. Then we would bring on a new developer and they would struggle to figure what the heck was going on with our application. We would have to patiently walk them through some things until things started to click. I have a feeling that Guice would have made this less painful for new developers, though there were definitely things we did with Spring (especially using its AOP support in conjunction with DI) that I'm not sure you could do with Guice.