Static fields in specialized classes
Brian Goetz
brian.goetz at oracle.com
Tue Oct 14 23:59:42 UTC 2014
> My gut feeling is that this is undesirable and should be disallowed,
> and that perhaps we shouldn't even be able to observe Foo<int>.class
> at all.
If you think about the problem a little more, I think you'll find that
this is wishful thinking. (But of course, you're free to have a gut
feeling without having thought about it at all.)
> After all, if specialization is intended to be viewed primarily as an
> implementation detail
It is an implementation detail in the same sense that erasure is; that
generics are implemented by erasure almost certainly leaks into the
user's perception too. (Erasure is why you can't have
Foo<String>.class, for example. Among many other things that the user
has to pay attention to.)
class Foo<any T> {
T get() { ... }
}
Consider the members of various instantiations of Foo.
The signature of get() in Foo<String> is "String get()", but the
signature of get() in Foo<int> is "int get()". The erasure of the first
is "Object get()"; the erasure of the second is "int get()". While all
erased reference instantiations can be implemented by the same class,
the primitive/value instantiations cannot be.
Similarly, Foo<int> can't extend Foo<?> (because that really means Foo<?
extends Object>, and has to for compatibility reasons), nor can it
extend raw Foo. (Which is fine; raw types exist solely to support
migration from ungenerified codebases to generified ones.)
We could hide the existence of List<int>.class, but that would just make
life harder for users, who would then have to jump through bigger hoops
to reflect over the members of List<int> (which are different from the
members of List<String>, even after erasure.)
> In other words, while the Java language/library changes may be
> expressed by some improvements to reflection, I'd be concerned about
> the many implemented algorithms based on reflection.
It is of course reasonable to be concerned. Stay tuned and see if your
concerns are addressed.
More information about the valhalla-dev
mailing list