standardizing DI across frameworks (Bob Lee)

[gonorrhea]

Google Guice and SpringSource have partnered to standardize a proven, non-controversial set of annotations that make injectable classes portable  across frameworks.

http://crazybob.org

what affect, if any, will this have on 299?

Bob:

299 is an EE specification and it specifies its own approach to configuration. In contrast, our specification's only requirement is the Java Programming Language v5, and configuration is left up to the injector implementation. 299 could be one such compatible injector implementation if the EG decides to adopt these annotations.

[nickarls]

Very little. Gavin already blogged about it here and there was a trout-slapping-session over here already. Nothing to see here, move along ;-)

[gonorrhea]

I actually read most of the TSS thread.  Somewhat educational, mostly angry/argumentative.  Not unusual...

[gavin.king]

From our point of view it's not really very interesting. It's a set of annotations that do the same thing that the 299 annotations already do, but with different names and under-defined semantics. If the JSR gets approved, we can easily support these annotations since they are a subset of what 299 already defines. However, IMO, there's not much value to defining the annotations you use to inject stuff without also defining what things can be injected, how you configure injection, what standard set of scopes are available and what is there behavior, how do you write portable extensions, etc.

[gonorrhea]

Ok.  Now forgive my ignorance, as I have not had much time to dive into the 299 spec, but consider this:

JCDI is not just a set of annotations that lets you inject things. It's the key to an ecosystem that allows Java EE developers to easily wire together their Java EE components and services using portable code, framework developers to write portable extensions that integrate with the container, and deployers to reconfigure the system with minimal XML.

source: http://in.relation.to/Bloggers/Gavin

What about swing developers who need DI standards, for example?  Or simply Java SE in general?  I think I've heard you state on some blogs that 299 can provide DI support for Java SE as well, but that is not the focus and intention of 299 it seems (or at least not advertised as such).

It really seems to me that there should be a separate DI spec that covers Java SE independently or 299 should cover and provide standards for Java SE and JEE together.

But I am also completely unaware of the political ramifications of doing so (and timelines of course) in JCP.

just my .02.

[gonorrhea]

Based on my limited knowledge, I'd have to agree with this gentleman's statements conceptually:

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

source: http://www.adam-bien.com/roller/abien/entry/spring_guice_jsr_299_just

[gavin.king]

Sure, SE developers need this stuff too. But they already have it: they can use Guice, Spring or Web Beans in Java SE, with minimal fuss.

But if we're going to make these annotations live in the JDK, there needs to be a full definition of their semantics and how you can use them to build a portable application. What the hell is the point of having just the annotations in the JDK if the JDK does not actually include a container which provides support for them?! And if every container that actually does support them, supports them in it's own, special, non-portable flavor?

[gavin.king]

Look, if you really want a portable DI layer in SE, the most direct route is to subset 299 for SE. It is not to introduce a set of under-specified annotations, with no container that supports them, into the JDK. But of course, if I were to try and propose that we subset 299 for Java SE, SpringSource and Google would be the very first to jump up and down and vote that proposal down, because they don't actually want to compromise on what their existing proprietary solutions currently do in order to achieve portability. Sad but true.