Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JSR 330 support #424

Closed
gissuebot opened this issue Jul 7, 2014 · 4 comments

Comments

@gissuebot
Copy link

@gissuebot gissuebot commented Jul 7, 2014

From limpbizkit on September 07, 2009 13:57:10

I'm going to add this today.

The first controversial issue I've run into: should we coalesce @Named and @Named? It would be
quite frustrating to bind one @Named and inject another; and the error message wouldn't be very
easy to parse.

Original issue: http://code.google.com/p/google-guice/issues/detail?id=424

@gissuebot

This comment has been minimized.

Copy link
Author

@gissuebot gissuebot commented Jul 7, 2014

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

@gissuebot

This comment has been minimized.

Copy link
Author

@gissuebot gissuebot commented Jul 7, 2014

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...

@gissuebot

This comment has been minimized.

Copy link
Author

@gissuebot gissuebot commented Jul 7, 2014

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

@gissuebot

This comment has been minimized.

Copy link
Author

@gissuebot gissuebot commented Jul 7, 2014

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.

@gissuebot gissuebot closed this Jul 7, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.