Spring + Guice + JSR-299 = Just Good Friends?

Spring together with Google are going to propose a JSR which will standardize/unify the injection principles in both frameworks:

"...We propose to specify annotations to enable the reuse of injectable classes across multiple dependency injection frameworks..."

The spec leads are Rod Johnson (SpringSource) and Bob Lee (Google). Bob is spec lead in JSR-299 as well, so it might help in the standardization process. It would be the best, if this JSR would even make into JDK. The DI approach is Guice-like and annotation based.

These are really good news. Hopefully the JSR gets accepted and makes as soon as possible into a standard.


NEW online workshop: Web Components training (online)

Airport MUC workshops: Java EE 8, Java 9: Bootstrap, Effective, Architectures, Single Page Apps, Progressive Web Apps, HTML 5, ES 6, CSS 3 and Microservices

Podcast: airhacks.fm and newsletter: airhacks.news

A book about rethinking Java EE Patterns

Comments:

JPA for Dependency Injection is coming. Nice news.

It seems that this is a new path to introduce new Java language features. Create library of framework, get competitor, introduce JCR and later they can come directly to Java language. Long way, but very secure, no sheet will come inside until it properly tested.

Only one little disadvantage, even perfect ideas takes too long to come inside.

Still very glass

Posted by Remis B on May 06, 2009 at 10:06 AM CEST #

Please note that Bob Lee is actually not very happy about JSR 299: http://www.mail-archive.com/google-guice@googlegroups.com/msg01291.html
http://www.mail-archive.com/google-guice@googlegroups.com/msg01250.html
etc. You can google for more...

Posted by Eberhard Wolff on May 06, 2009 at 10:10 AM CEST #

Adam,

Bob wrote a couple of weeks ago on the guice-dev mailing list that he stopped being involved in JSR299 a year ago:

"If 299 looks superficially like Guice, it's because I was heavily involved.
I left the EG over a year ago because I disagreed with the leadership and
technical direction.

So far, I haven't bothered to actively oppose 299 for a few reasons:

1) 299 doesn't seem to have gained any real traction. Only RedHat is
pushing it. You've heard of design by committee? 299 is design by Gavin. :-)

2) 299 is part of EE, which we don't use or care much about. I think the
risk of 299 imposing itself on SE is zero.

3) I choose to spend my time constructively (on the Java language, Guice,
JSR 166, Android, etc.), not playing political games.

My advice to our users is to continue using the Guice API. Your code will be
more maintainable as a result. JSR 299 does not represent consensus. It's a
land grab by unqualified vendors who would rather prematurely set an
unproven design in stone than compete on a level playing field. It's EJB and
JSF all over again. By comparison, the Guice API has enjoyed many times the
scrutiny by people who actually use and understand this stuff. Guice is
simpler, better specified and more future proof as a result.

In other words, Guice will not directly support 299, but you could easily
build a 299 extension for Guice. You'd be better off sticking to the Guice
API though.

Bob"

Cheers,

S. Fermigier, Nuxeo

Posted by Stefane Fermigier on May 06, 2009 at 10:29 AM CEST #

The biggest problem with the entire JSR 299 thing is, that it is tied to JavaEE land.

Unfortunately there was never a flexible and extensible DI layer in JavaSE land.

JSR 299 basically puts DI into EE land. There will be a "tomcat-ready" impl. of it, but still using EJB-light doesn't sound like fun...

IMO the best would have been if the starting point of JSR 299 would have been a flexible DI way, in JavaSE.

JSR299 could have just used that one to provide all the EJB/EE requirements and more folks would be happy.

Now, this proposal comes a little bit late... This should have happened before 299... but that's life, I guess

Posted by Matthias Wessendorf on May 06, 2009 at 11:47 AM CEST #

So: Who needs another annotation-package for DI?

There is a javax.annotation.Resource which "marks a resource that is needed by the application" (see javadoc). This annotation can be applied to Fields, Types and Methods. And EVERY container (including Spring, Guice and EJB) should provide the desired resource here via DI.

Why do we need something else?

Are annotations the next nightmare after that orgiastic use of XML like spring does?

Robert

Adam: Won a T-Shirt for these heretical questions? ;-)

Posted by Robert on May 06, 2009 at 12:58 PM CEST #

Please note that Gavin King is the spec lead for JSR-299, not Bob Lee.

Posted by Dan Allen on May 06, 2009 at 07:13 PM CEST #

Yet another JSR no one needs. I think Web Beans SE Extension fits best for those needs and JSR299 is not carved in stone.

Posted by Benjamin on May 06, 2009 at 10:50 PM CEST #

cool. A standard dep. injection framework would fit pretty well to the jdk module system jigsaw.

Looking forward to see a jdk-core package in the linux repositories.
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2009-May/000090.html

But nowadays starting a JSR can be compared to starting a religions war :/ I hope this jsr won't die - looks pretty good for me.

Posted by mbien on May 07, 2009 at 01:51 PM CEST #

@Benjamin: YOU may not need JSR 299, but there are plenty of people who do. If you write server-side apps and use JPA (which really is very nice in many situations), you need to reach your entity beans from your web framework. JSR 299 has by far the cleanest solution that I have seen.

Posted by Cay Horstmann on June 20, 2009 at 07:28 AM CEST #

There is also implementation of the JSR 299, namely OpenWebBeans. You can reach the website at http://incubator.apache.org/openwebbeans.

Posted by Gurkan Erdogdu on September 09, 2009 at 04:09 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
realworldpatterns.com
Online Workshops
...the last 150 posts
...the last 10 comments
License