Static fields in specialized classes

[Brian Goetz]

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

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.

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.

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.

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.

Except for MH lookup.  Will need to fix that up too.

Any others?