Static fields in specialized classes

[Vitaly Davidovich]

Why should this be disallowed in the language (whether it's a good idea to
write that as a developer is a different story)? Suppose you have a
non-generic class with that generic method, but then you also have some
specialization for Foo<int> (again, good or bad idea from design standpoint
aside).  If we're not erasing generics anymore, then I don't see anything
unsound from a type system perspective (overload resolution would pick the
most precise, favoring non-generic methods over generic).

Also, this wouldn't break any existing code since that's not possible today
with erasure, so would be safe from a backcompat viewpoint.

As a slight tangent to this, it would be nice if we can finally implement
the same generic interface on a class with different types, e.g.:

interface Message {}
class Message1 implements Message {}
class Message2 implements Message{}

interface Handler<M extends Message> { void handle(M msg); }

class MyHandler implements Handler<Message1>, Handler<Message2> {
     void handle(Message1 m) {}
     void handle(Message2 m) {}
}

On Tue, Oct 14, 2014 at 6:16 PM, Stephen Colebourne <scolebourne at joda.org>
wrote:

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