From limpbizkit on September 07, 2009 12:52:30

I've made Guice's Provider extend the JSR 330 class. This should make it easier to interoperate with the new API.
We could also change the code where we accept a com.google.inject.Provider to instead accept a
javax.inject.Provider, but that would break binary compatibility.

As a compromise, I'll make it so that Guice:
 - always returns com.google.inject.Provider
 - accepts javax.inject.Provider, wherever it does not break binary compatibility.

Status: Started

From limpbizkit on September 07, 2009 14:02:50

From the commit log of r1077 :

This checkin supports:
   @javax.inject.Inject to mark classes
   @javax.inject.Qualifier to identify binding annotations
   javax.inject.Provider injections
   A new Jsr330 utility class

Still outstanding:
   JSR 330 is more strict about where its annotations are applied. These
restrictions are not yet enforced.
   @Scope
   @Singleton

Notable change:
   When the user injects a javax.inject.Provider<T>, we canonicalize the
dependency, and treat it exactly as if they injected a
com.google.inject.Provider<T>. This is slightly weird! For example, these two
keys are equal:
Key.get(new TypeLiteral<javax.inject.Provider<String>>() {})
Key.get(new TypeLiteral<com.google.inject.Provider<String>>() {})
   This is convenient, particularly for SPI users. And it means we don't need a
linked binding between the Providers. But it could be quite surprising. I'm
still trying to decide the right long term solution here...

From limpbizkit on September 07, 2009 17:36:39

r1078 , r1079 and r1080 complete the implementation. I've opened issue 425 to address the @Named problem; I
believe everything else is in place.

Status: Fixed

From miroslav.pokorny on December 06, 2010 00:49:52

Why has this not officially been released ? Only 2.0 and a 3.0 snapshot are available...tehre is no 2.1.