Static fields in specialized classes

[Stephen Colebourne]

On 13 October 2014 19:19, Brian Goetz <brian.goetz at oracle.com> wrote:
> Except for reflection; reflection on Foo<int>.class should still show that
> it has the same static members as Foo, and in fact they *are* the same
> static members.  So then we're done.

The suggestion that there will be a Foo<int>.class as well as a
Foo.class is one that must have implications on logic in end user
programs. Today, I can assume that if there is a method

void process(Foo<T>)

then it cannot be overloaded, but I presume that the existence of
Foo<int>.class implies that you can overload now?

void process(Foo<T>)
void process(Foo<int>)

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.

After all, if specialization is intended to be viewed primarily as an
implementation detail, just like erasure, then shouldn't it be
directly observable in Java code based on Class just like erasure. ie
a Class remains as a single template, with a Type remaining as the
type system type, and perhaps with a third intermediate form added
between the two - "Specialism" or some such name).

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.

Stephen