Discussion:
Java 8 Type Annotations and Guice
Josh Powell
2018-05-04 21:26:17 UTC
Permalink
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.
It looks like there are bugs in the current release's handling of
https://bugs.openjdk.java.net/browse/JDK-8039916. That prevents the
constructor or method parameter; it only works on fields right now. I
least so I'll try to write that part.
http://stackoverflow.com/questions/23025363/how-to-get-generic-type-information-from-getannotatedparametertypes-in-java-8/23066816.
Hopefully there's a workaround.
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
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.
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
Something cool just occurred to me, it'd be nice to be able to write new
// 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;
}
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.
Heh. I just made an issue for exactly that purpose.
c.
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.
[snip]
--
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
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
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 https://groups.google.com/group/google-guice.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/e77e2fa5-5ce8-4183-8eca-d117ce9a68a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Loading...