Today, we hope to give developers the best of both worlds. Google Guice and SpringSource have partnered to standardize a proven, non-controversial set of annotations that make injectable classes portable across frameworks. At the moment, the set of specified annotations consists of:
- @Inject - Identifies injectable constructors, methods, and fields
- @Qualifier - Identifies qualifier annotations
- @Scope - Identifies scope annotations
- @Named - String-based qualifier
- @Singleton - Identifies a type that the injector only instantiates once
- Provider<T> - Provides instances of a type T. For any type T that can be injected, you can also inject Provider<T>.
The expert group will be inclusive and will work in the open. For example, our mailing list is publicly readable, and we host the specification at Google Code. Several industry players have already expressed interest in supporting this effort. Contact us if you'd like to help out.
Interested in learning more about dependency injection? Don't miss Jesse and Dhanji's Big Modular Java with Guice session at Google I/O!
how would this relate to jsr 299?
ReplyDeleteShould have actually looked at the proposal :-)
ReplyDelete"JSR 299 is defining a dependency injection framework for Java EE, and might support these annotations."
"I don't get Spring" ->
ReplyDeleteJoins JSR299 ->
Leaves JSR299 ->
"Why don't we all submit modest proposals and then
go around standardizing whatever we feel like regardless of the scope,
skipping that whole messy step where you have to actually work w/ other
people and achieve consensus?" ->
"Google Guice and SpringSource have partnered to standardize a proven, non-controversial set of annotations that make injectable classes portable across frameworks"
Well, it's late and I'm probably missing something...
I prefer JSR299. This new JSR are Spring vs Red Hat competition
ReplyDeleteThe new JSR is rocking BIG TIME. I have wished for dependency injection right in Java for months after fully having watched the Testable-Code Talks by Misko Hevery.
ReplyDeleteTo finally see this happen is absolutely GREAT!
Actually, from what I see, it is only the names of the annotations that are being proposed for standardization.
ReplyDeleteUnder the JSR-299 umbrella, I understand that there are subprojects under both the WebBeans RI and OpenWebBeans that aim for Java SE injection as an extension. Under the "original" annotations.
For what I see the spec is pretty thin atm.
ReplyDeleteSo what is it for? Portability? Then it should also homogenize the configuration. Because without this I cannot move my application nor even take single jars with a single functionality written for a different implementation.
JSR-299 should imho be stripped down to the core. All the 'additional EE functionality' like JPA, JSF, EJB, JMS etc should be specified but should be marked as optional or considered to be moved to JSR-313 (EE6).
JDK-only is btw already the default for JBoss RI and OpenWebBeans as someone mentioned already. It's 'only' not in the written spec yet, but that might be easy.
So I personally don't get the point what the benefits of this proposal would be for a real world programmer.
LieGrue,
strub
PS: the javax.inject is already reserved by JSR-299 as you surely know...
Thanks, Daniel K!
ReplyDeleteLeonardo, Nik, struberg, this proposal doesn't compete with JSR-299. In fact, I sent it to the JSR-299 EG lead over a week ago and have already addressed his comments. Please coordinate with him.
JSR-299 can go on just as before. RedHat has told me that the 299 annotations will be under javax.ee.inject in the final spec. If JSR-299 decides to join Guice, Spring, PicoContainer et al in supporting these annotations, that would be great for the Java community.
This is exactly the sort of crap I would expect from Microsoft.
ReplyDeleteBob,
ReplyDeleteFirst, thanks for your answer!
Your comment suggerates that the JSR-299 spec lead offered to move under javax.ee, but wasn't it exatly the other way round?
At least that's what I heard of a few involved people and also that's exactly what I can read black on white on googles comment to the JSR-299 public review ballot:
On 2009-02-09 Google Inc. voted Yes with the following comment:
Google votes yes with the understanding that if the spec name is changed, the new name will be "Contextual Dependency Injection for Java EE," and that all of the new package names introduced will have the "javax.ee" prefix.http://jcp.org/en/jsr/results?id=4748
A lot of people have been pretty distressed with this comment, and as of yet, I can see no javax.ee in the official Spec nor in the RI.
But don't get me wrong: I'm completely with you that we should have an IOC standard which is also meant for SE and not only for EE environments!
LieGrue,
strub
struberg, my comment doesn't suggest anything. I was just responding to your comment: "PS: the javax.inject is already reserved by JSR-299 as you surely know." We do think that javax.ee.inject is a more appropriate package for 299 given its EE bias, as do several other EC members.
ReplyDeleteMy first though is OMG no.
ReplyDeleteI'm really puzzled. At first glance this seems very strange but I like Guice a lot so I'm trying to work out what I'm missing here.
As far as I can see this will solve a small but identical subset of the problem that 299 has already addressed. 299 already has a working reference implementation (and another on the way) and will be in EE 6 this year. It is part of Java EE rather than Java SE but the requirements for 299 make is perfectly possible to take it out and run it in SE with a container - Tomcat or whatever. 299 will be available from September. So why not use it? Or why not take the subset of 299 that you want in the base SE platform and refactor 299 slightly as appropriate. Does Java really benefit from having two separate, competing standards for DI?
Please make sure this happens. Gavin's pov is way too narrow. There's life beyond the JBoss application server and JEE app servers in general.
ReplyDeleteI for one also make command line apps, games and Swing apps, none OF WHICH are in the ee space. How the hell is 299 supposed to meet my needs? Gavin's being his typical closed stubborn self.
To the greater audience, THERE IS LIFE BEYOND YOUR CRAPPY JAVA EE WEBAPP.
ReplyDeleteThe need for standardized annotations is clear, see my comment above. There are a lot of people like me who I'm sure would want this to happen.
Charles, the idea is that 299 will reuse these annotations instead of defining its own. The design of this spec was informed by 299 as well as Spring and Guice. We shouldn't have two competing standards (unless the 299 EG decides to go their own way, but I don't see why they would).
ReplyDeleteThanks, Ivan! Don't worry. The majority sees the benefit in this spec. Our friends at RedHat JBoss will come around. :-)
Great idea, period.
ReplyDeleteInstead of having all these things for Java EE in JSR-299 we need a global way of Java dependency injection. Then JSR-299 and a lot of other API's can benefit from it.
Don't try to do too much in a single JSR, break it into smaller managable pieces.
That's why I think JSR-299 should adopt this new JSR when its finished.
But I do have some doubts about this proposal, but that might just be because I haven't used Guice in a project yet. Would love to see some more examples.
Very gratified to see this happen.
ReplyDeleteThank you very much. Greetings!
Ivan: "How the hell is 299 supposed to meet my needs? ". Easy, see my comment here. As Charles rightly points out, 299 in SE is not a far cry from the EE spec.
ReplyDeleteBob: "Charles, the idea is that 299 will reuse these annotations instead of defining its own." But 299 was here first, so ... huh?
Should look at http://relation.to/Bloggers/Gavin
ReplyDeleteand JSR-299 presentation at Sun
http://relation.to/service/File/10946
isn't it awesome ?
Coveres almost all the features and supports all JEE standards