Wednesday, December 9, 2009

Thoughts on JSR 330

I'm not sure what to think about JSR-330 -- what do you think?

A quick caveat before I begin -- I'm playing devils advocate here, so I have no idea if I believe any of the gibberish that I'm about to write :)

On one hand, I think it's Mostly Harmless... CDI/JSR-299 is obviously the default implementation of the spec, and perhaps having a very small portion of the DI capability abstracted so that we have the choice to use another framework if we want isn't necessarily a bad thing (even if standardizing injection targets isn't exactly ground breaking value) -- after all, if it weren't for those 'outside' framework writers, we might not have gotten EJB 3, and all the improvements that came along with Java EE 5... perhaps JSR 330 is a way to bring those folks inside of the Java EE fold, so it's not another three years before the standards catch up with the private innovation

On the other hand, is it at all likely that an application would be able to just replace the DI capability of CDI with, say, Spring or Guice, but still use the contexts, interceptors, extensions, etc? After all, Dependency Injection is actually a pretty small part of what the CDI spec provides... Perhaps, if one were to write a CDI Portable Extension that basically vetos all bean discovery, and instead uses one of the other libraries to do the injection, but that seems like a stretch to me...

What seems more likely is that another implementation would simply not use CDI, which can easily be done by not providing a beans.xml file, and using some other mechanism, like the Spring WebApplicationContext -- in that case, is there value in what the JSR-330 spec provides? Has the addition of this spec, which provides little value in-and-of itself incorporated too much confusion?

My original instinct was that it's a good addition to the Java EE fold, but I've heard a few voices of opposition (including from those who don't have a big stake in the outcome)... now I think, perhaps, that I could take it or leave it -- I haven't been convinced that it's destructive, but I'm also not convinced that it's worth it :)

What do y'all think?

M


4 comments:

Anonymous said...

As shocking as this might be to you :-), there is more to life than webapps. In particular, JSR-330 gives Java SE based apps a nice clean *standard* way to use annotation based dependency injection, without having to preselect whether you want to use Spring or Guice or something else for the implementation.

Gavin said...

"In particular, JSR-330 gives Java SE based apps a nice clean *standard* way to use annotation based dependency injection, without having to preselect whether you want to use Spring or Guice or something else for the implementation."

Well, the problem is that it *doesn't* do that. There's no way to write an application using only JSR-330 APIs. You will have to use Guice or Spring APIs or XML just to inject a simple bean. Sad, but true.

"there is more to life than webapps."

Agreed. That's why the CDI reference implementation, Weld, runs really, really nicely in Java SE.

Matt Corey said...

@Anonymous -- good point, there's more than just webapps... but how does that change anything? Ok, how about this -- we could have a domain model in a Swing app which uses Guice to wire itself together... we get a new requirement to put a web front-end on the application, or add new features that are available through the browser -- when we dig in here, we find some features of CDI or Swing that we weren't aware of before which could be valuable... is it reasonable to leave behind our Guice Modules and expect CDI to be able to fill in? Perhaps -- I'll have to stew on that a bit...

M

Shalini said...

Superb. I really enjoyed very much with this article here. Really it is an amazing article I had ever read. I hope it will help a lot for all. Thank you so much for this amazing posts and please keep update like this excellent article.thank you for sharing such a great blog with us. expecting for your.

seo company in india