Java 8 Type Annotations and Guice

[Tavian Barnes]

Java 8 allows annotations to appear everywhere a type is used, which allows for things like

Provider<@Named("name") Thing> provider;

instead of

@Named("name") Provider<Thing> provider;

The first way, to me, seems more semantically accurate, because it reads "provider of named thing" rather than "named provider of thing." However, there would obviously be a lot of complication in choosing to support this syntax.  It would be difficult to use the new AnnotatedType reflection APIs and still support Java 6/7.  Ambiguous cases like

@Named("name") Provider<@Named("otherName") Thing> provider;

would have to be detected too.  Of the three choices:

(1) Ignore binding annotations on types

(2) Support binding annotations on types

(3) Give a warning/error for binding annotations on types,

I assume Guice is sticking with (1) for now?  If someone wrote a patchset to support AnnotatedTypes in a backwards-compatible way (strategy pattern for example), would (2), (3), or neither be most likely to get merged?

[Sam Berlin]

I'd be open to any of the following:

  a) Hard-error on a qualifer/bindingannotation on types

  b) Support qualifer/bindingannotation on types, but fail if it also exists on the variable

Though, since this'd be a change to the way jsr330 things are interpreted, seems like it'd be best to poll the jsr330 folks and make sure all various implementations (Dagger, Spring, etc..) are on-board with the same solution.

 sam

--
You received this message because you are subscribed to the Google Groups "google-guice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-guice...@googlegroups.com.
To post to this group, send email to google...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-guice.
For more options, visit https://groups.google.com/d/optout.

[Tavian Barnes]

On Monday, 7 April 2014 17:47:48 UTC-4, Sam Berlin wrote:

I'd be open to any of the following:

  a) Hard-error on a qualifer/bindingannotation on types

  b) Support qualifer/bindingannotation on types, but fail if it also exists on the variable

Makes sense. I do think one of them should be done before Guice 4.0 is out since that'll be the first release supporting Java 8 anyway. I'll try to cook up a patch for (a) and then (b) on top of it.

 

Though, since this'd be a change to the way jsr330 things are interpreted, seems like it'd be best to poll the jsr330 folks and make sure all various implementations (Dagger, Spring, etc..) are on-board with the same solution.

Good point. The atinject list seems dead though, should I post there or manually poll Dagger, Spring, HK2, CDI, etc.?

[Sam Berlin]

Yeah, I'd try the atinject list & if it gets no response, try the individual lists.  Hopefully it won't be too controversial a question.

 sam

[Tavian Barnes]

Well the atinject list isn't publicly writeable, but I submitted an issue at https://code.google.com/p/atinject/issues/detail?id=28 which got posted to the list too so hopefully people see it.

Also atinject-observer seems broken, it's missing all 4 posts from 2012 and later.

[Christian Gruber]

Filing the issue is good. I'm going to end up chatting with Jesse
Wilson tomorrow, and I think we can chat through the Dagger side of
things. If no action is heard on the issue, we can reach out to the
spring and CDI folks directly.

On 8 Apr 2014, at 8:48, Tavian Barnes wrote:

> Well the atinject list isn't publicly writeable, but I submitted an
> issue
> at https://code.google.com/p/atinject/issues/detail?id=28 which got
> posted
> to the list too so hopefully people see it.
>
> Also atinject-observer seems broken, it's missing all 4 posts from
> 2012 and
> later.
>
> On Tuesday, 8 April 2014 11:29:03 UTC-4, Sam Berlin wrote:
>>
>> Yeah, I'd try the atinject list & if it gets no response, try the
>> individual lists. Hopefully it won't be too controversial a
>> question.
>>
>> sam
>>
>>
>> On Tue, Apr 8, 2014 at 11:26 AM, Tavian Barnes

>> <tavia...@gmail.com<javascript:>

>>> email to google-guice...@googlegroups.com <javascript:>.

>>> To post to this group, send email to

>>> google...@googlegroups.com<javascript:>
>>> .

>>> Visit this group at http://groups.google.com/group/google-guice.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "google-guice" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to google-guice...@googlegroups.com.
> To post to this group, send email to google...@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-guice.
> For more options, visit https://groups.google.com/d/optout.

Christian Gruber :: Google, Inc. :: Java Core Libraries :: Dependency
Injection
email: cgr...@google.com :::: mobile: +1 (646) 807-9839

[Tim Peierls]

On Mon, Apr 7, 2014 at 5:47 PM, Sam Berlin <sbe...@gmail.com> wrote:

I'd be open to any of the following:

  a) Hard-error on a qualifer/bindingannotation on types

  b) Support qualifer/bindingannotation on types, but fail if it also exists on the variable

Though, since this'd be a change to the way jsr330 things are interpreted, seems like it'd be best to poll the jsr330 folks and make sure all various implementations (Dagger, Spring, etc..) are on-board with the same solution.

The 330 spec says that "A qualifier annotation

• may have restricted usage if annotated with @Target. While this specification covers applying qualifiers to fields and parameters only, some injector configurations might use qualifier annotations in other places (on methods or classes for example).

I was on the 330 EG. My memory is that this wording was chosen specifically to allow for the future use of type annotations, which were at that point in an "any day now" state (and had been for quite some time).

--tim

[Tavian Barnes]

That actually brings up a pain point for doing this in Guice: adding ElementType.TYPE_USE to the targets for @Named would make Java 8 required to build Guice.  Not sure how feasible that is for Google.

JSR 330's @Named doesn't have that problem because it doesn't limit @Named's targets at all.

[Sam Berlin]

We can't limit the build enviroment to Java 8, but we could remove the restrictions on @Named's target types.

 sam

--

[John Wells]

Yeah, I would be against anything in JSR-330 (or whatever extension thereof) that would force a requirement of Java 8

--

[Christian Gruber]

It's Guice's @Named that's an issue, not javax.inject, which does not
restrict. As sam said in a sister post, we should just un-encumber
@Named with the element type restrictions, and we can provide
alternative means to restrict if we want to clamp down (annotation
processors or error-prone which can be selectively applied).

Dagger will also need to loosen its limitations, but it implements them
with annotation processors, and uses the javax.inject version of @Named,
so I think we can get all of this consistent at least with respect to
Guice-derived injector systems.

c.

On 8 Apr 2014, at 9:50, John Wells wrote:

> Yeah, I would be against anything in JSR-330 (or whatever extension
> thereof) that would force a requirement of Java 8
>
>
> On Tue, Apr 8, 2014 at 12:41 PM, Tavian Barnes <tavia...@gmail.com>
> wrote:
>
>> That actually brings up a pain point for doing this in Guice: adding
>> ElementType.TYPE_USE to the targets for @Named would make Java 8
>> required
>> to build Guice. Not sure how feasible that is for Google.
>>
>> JSR 330's @Named doesn't have that problem because it doesn't limit
>> @Named's targets at all.
>>
>> On Tuesday, 8 April 2014 12:18:49 UTC-4, Tim Peierls wrote:
>>
>>> On Mon, Apr 7, 2014 at 5:47 PM, Sam Berlin <sbe...@gmail.com> wrote:
>>>
>>>> I'd be open to any of the following:
>>>> a) Hard-error on a qualifer/bindingannotation on types
>>>> b) Support qualifer/bindingannotation on types, but fail if it also
>>>> exists on the variable
>>>>
>>>> Though, since this'd be a change to the way jsr330 things are
>>>> interpreted, seems like it'd be best to poll the jsr330 folks and
>>>> make sure
>>>> all various implementations (Dagger, Spring, etc..) are on-board
>>>> with the
>>>> same solution.
>>>>
>>>
>>> The 330 spec says that "A qualifier annotation
>>>

>>> - may have restricted usage if annotated with @Target. While this

[Tavian Barnes]

What about tests?  It seems difficult to test something like this without some test classes that actually use type annotations somewhere.

Right now my idea is to put Java 8 specific tests in a special package, and exclude that package unless a special Maven profile is activated.  I assume something equivalent is possible with Ant.

[Christian Gruber]

Heh. I just made an issue for exactly that purpose.

c.

On 8 Apr 2014, at 13:57, Tavian Barnes wrote:

> What about tests? It seems difficult to test something like this
> without
> some test classes that actually use type annotations somewhere.
>
> Right now my idea is to put Java 8 specific tests in a special
> package, and
> exclude that package unless a special Maven profile is activated. I
> assume
> something equivalent is possible with Ant.
>
> On Tuesday, 8 April 2014 12:55:56 UTC-4, Sam Berlin wrote:
>>
>> We can't limit the build enviroment to Java 8, but we could remove
>> the
>> restrictions on @Named's target types.
>>
>> sam
>>
>>
>> On Tue, Apr 8, 2014 at 12:41 PM, Tavian Barnes

>> <tavia...@gmail.com<javascript:>

>>> wrote:
>>
>>> That actually brings up a pain point for doing this in Guice: adding
>>> ElementType.TYPE_USE to the targets for @Named would make Java 8
>>> required
>>> to build Guice. Not sure how feasible that is for Google.
>>>
>>> JSR 330's @Named doesn't have that problem because it doesn't limit
>>> @Named's targets at all.
>>>
>>> On Tuesday, 8 April 2014 12:18:49 UTC-4, Tim Peierls wrote:
>>>
>>>> On Mon, Apr 7, 2014 at 5:47 PM, Sam Berlin <sbe...@gmail.com>
>>>> wrote:
>>>>
>>>>> I'd be open to any of the following:
>>>>> a) Hard-error on a qualifer/bindingannotation on types
>>>>> b) Support qualifer/bindingannotation on types, but fail if it
>>>>> also
>>>>> exists on the variable
>>>>>
>>>>> Though, since this'd be a change to the way jsr330 things are
>>>>> interpreted, seems like it'd be best to poll the jsr330 folks and
>>>>> make sure
>>>>> all various implementations (Dagger, Spring, etc..) are on-board
>>>>> with the
>>>>> same solution.
>>>>>
>>>>
>>>> The 330 spec says that "A qualifier annotation
>>>>

>>>> - may have restricted usage if annotated with @Target. While this

>>>> specification covers applying qualifiers to fields and parameters
>>>> only,
>>>> some injector configurations might use qualifier annotations in
>>>> other
>>>> places (on methods or classes for example).
>>>>
>>>> I was on the 330 EG. My memory is that this wording was chosen
>>>> specifically to allow for the future use of type annotations, which
>>>> were at
>>>> that point in an "any day now" state (and had been for quite some
>>>> time).
>>>>
>>>> --tim
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups
>>> "google-guice" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an

>>> email to google-guice...@googlegroups.com <javascript:>.

>>> To post to this group, send email to

>>> google...@googlegroups.com<javascript:>
>>> .

>>> Visit this group at http://groups.google.com/group/google-guice.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>
> --
> You received this message because you are subscribed to the Google
> Groups "google-guice" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to google-guice...@googlegroups.com.
> To post to this group, send email to google...@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-guice.
> For more options, visit https://groups.google.com/d/optout.

[Tavian Barnes]

Something cool just occurred to me, it'd be nice to be able to write new Key<@Named("foo") String>(){}.

Anyway I think type annotations need a little more thought.  If Provider<@Named("foo") String> works, why not this:

// Attempt to simulate Dagger's Lazy<T>

public class Lazy<T> {

  @Inject Provider<T> provider;

  private T instance;

  public synchronized T get() {

    if (instance == null) instance = provider.get();

    return instance;

  }

}

public class Foo {

  @Inject Lazy<@Named("foo") String> lazy;

}

Does the @Named("foo") follow the type parameter into the implementation of Lazy?  If not, then I guess any binding annotations on type arguments should cause an error unless they're on the argument to a Provider.

On Tuesday, 8 April 2014 17:06:05 UTC-4, Christian Gruber wrote:

Heh.  I just made an issue for exactly that purpose.

c.

On 8 Apr 2014, at 13:57, Tavian Barnes wrote:

> What about tests?  It seems difficult to test something like this
> without
> some test classes that actually use type annotations somewhere.
>
> Right now my idea is to put Java 8 specific tests in a special
> package, and
> exclude that package unless a special Maven profile is activated.  I
> assume
> something equivalent is possible with Ant.
>
> On Tuesday, 8 April 2014 12:55:56 UTC-4, Sam Berlin wrote:

> [snip]

[Sam Berlin]

I love the annotation idea -- that would be a much simpler way using annotations with parameters, without requiring the user to make an implementation of it.

The "Lazy" one doesn't really follow from it, though.  "T" in Provider<T> would still be lost by erasure.  You'd need to subclass Lazy in order to store the information in the type system. 

 sam

--

[Tavian Barnes]

The Lazy example isn't related, I was just talking about the current process of resolving type parameters in just-in-time bindings.  The current behaviour will give Lazy a Provider<String> for that example. 

[Sam Berlin]

It will?  Smart.  Maybe it *is* possible to thread it through then, somehow.  Looks like this can get confusing real quickly... some experiments seem in order.

 sam

[Tavian Barnes]

It looks like there are bugs in the current release's handling of AnnotatedTypes that prevents this idea from working: https://bugs.openjdk.java.net/browse/JDK-8039916.  That prevents the annotation on Provider<@Named("foo") String> from being retrieved on a constructor or method parameter; it only works on fields right now.  I don't think it affects the new Key<@Named("foo") String>(){} idea at least so I'll try to write that part.

I asked this SO question about the bug: http://stackoverflow.com/questions/23025363/how-to-get-generic-type-information-from-getannotatedparametertypes-in-java-8/23066816.  Hopefully there's a workaround.

[Josh Powell]

Have there been any updates on this in the past four years? Judging from the documentation and from an experiment I just ran, it looks like the answer is now. It seems desirable to me for Guice to use type annotations to distinguish keys for all the reasons mentioned early on in this thread.