Static fields in specialized classes

[David Holmes]

On 14/10/2014 4:19 AM, Brian Goetz wrote:
> We stumbled across a few issues regarding static fields in specialized
> classes in the prototype.  There seems to be a reasonably
> straightforward solution but it does touch quite a number of things.
>
> Consider:
>
> class Foo<any T> {
>      public final static int x = System.currentTimeMillis();
> }
>
> Regardless of whether our implementation is by specialization or erasure
> (or both), logically there is just *one* field 'x' for any instantiation
> Foo<T>.

Having read the rest of the thread the premise here is that there is 
only one generic class regardless of how many generic types; and as 
statics are associated with a class it follows there is one static field 
shared across all those types. It's a sound, compatible view of the 
world. Of course people may ask for a per-specialization "static" field 
mechanism.

Does this mean that for each specialization getClass()/.class return 
different Class objects (ie a Class object per type)? I'll assume yes.

> If we take a naive approach to specialization, where we just copy
> members from Foo<any T> to Foo<int> during specialization, we end up
> with two 'x' fields (wrong).  So the specializer should strip out static
> members during specialization.  (If the base class has static members,
> we also need to add back a clinit member in Foo<int> to force loading of
> base Foo, to ensure that all instantiations of Foo<any T> have a
> consistent view of Foo's statics.)  So then we're done.

Seems to be implementation detail.

> Except for access through instances (yechh).  Here, the compiler needs
> to rewrite any references to f.x (where f is an instance of a
> specialization of Foo) to Foo.x, and we're done.

Didn't we deprecate that yet? :) Arguably javac should do this 
regardless of specialization - though the JLS would have to specify the 
conversion to ensure all javac's comply.

> Except for access control; if x is private, then we get an
> IllegalAccessError on any references to x from within Foo<int> to Foo.x.
>   Which means that Foo<int> has to be loaded as if with a host class of
> Foo.  (Just as defineAnonymousClass supports a host class, classdynamic
> will need to as well.)  So then we're done.

Is this an implementation issue? The access control rules can easily be 
updated to account for specializations and grant them access.

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

Distinct Class objects seem problematic in this regard. The conceptual 
model of statics being like instance fields of the associated Class 
object breaks down here. A Class object is not really a "class" object 
but a "type" object.

> Except for MH lookup.  Will need to fix that up too.
>
> Any others?

JVM TI and any other VM based introspection mechanisms.

David