M3 leaves us in a position to check off one of the outstanding issues, which is
that of specialization-specific statics.
Members of Java classes have historically been divided into static and instance
members; static members are associated with a class, and instance members with
an instance of a class.
When Java 5 extended the type system to support multiple TYPES that are
represented by the same CLASS (e.g., ArrayList<String> and ArrayList<Number>),
we had a choice; treat static members as belonging to the CLASS, or as
belonging to the TYPE. We chose the former, as that was consistent with the
translation strategy of erasure, and also maximized compatibility with existing
code. (When .NET did reified generics, they chose the opposite;
Foo<Number>.staticMember and Foo<String>.staticMember refer different
variables. That’s also a valid choice.)
The following program would be sensitive to this distinction:
class Foo<any T> {
static int count;
public Foo() { ++count; }
}
new Foo<String>();
new Foo<Number>();
In Java, this program would increment the common counter twice; under the
alternative interpretation, the counters Foo<String>.count and
Foo<Number>.count would each be incremented once.
Statics in Java work the way they do, and we’re not proposing we change that.
However, once we break the assumption that all instantiations of a
parameterized type are reference instantiations, we run into some issues with
existing code idioms. What follows is a proposed generalization of static
members in the spirit of Model 3.
The Problem
-----------
Java code frequently uses tricks like the following, that exploit the
assumption of erasure:
// Cached instance of an empty collection
private static final Collection<?> c = new EmptyCollection<?>();
// Factory method that dispenses the cached empty collections, suitably casted
public static<T> Collection<T> emptyCollection() { return (Collection<T>) c; }
The above trick works because of erasure; a Collection<?> has the same
representation as a Collection<String>, Collection<Integer>, etc, so we can
freely cast it about with no loss of type safety. But once we anyfy
emptyCollection(), we’re now hosed; we can’t cast a Collection<?> to a
Collection<int>. This leaves us without a means of coding this common idiom,
because static members currently are per-class, not per-instantiation.
Obviously, the above code must continue to mean what it means today. But we’d
also like a means of extending the above idiom more broadly than erased
generics.
Extending Statics to Specializations
------------------------------------
Our current model treats parameterizations of template classes like classes;
anywhere in the bytecode that one can refer to a Constant_Class, one can refer
to a Constant_ParameterizedType. (Whether they are actually classes, or more
like “species”, is an open question, but whatever they are, there’s a way to
write their name in the classfile.)
The existing prototype places static members of Foo<any T> on the erased
species Class[Foo], and translates access to static member m of Foo<any T> as:
xxxstatic Class[Foo].m
However, we are free to assign meaning to xxxstatic as applied to a member
reference whose owner is a parameterized type. Suppose we extend the current
set of member ownerships from { instance, static } to { instance, static,
specialization }. We could then access a per-specialization member using
xxxstatic on a member reference whose owner is a specialization.
The syntactic story is mostly a bikeshed; we’ll need some token to indicate
“per-specialization”; we’ll use the silly token __SpecializationStatic for now.
The access story is simple: static members continue to only be able to
reference other static members (and not class type variables); __SS members can
access static members and other __SS members, as well as class type variables;
instance members can reference static, __SS, and instance members.
The translation / classfile story is simple. Assume we have a spare flag bit
(we can synthesize one) for ACC_SPECIALIZATION_STATIC (ACC_SS for short.)
Static members are marked with ACC_STATIC; __SS members are marked with ACC_SS.
Accesses to static members continue to be translated as xxxstatic
Class[Foo].m; accesses to __SS members are translated as xxxstatic
ParamType[Foo,params].m.
The specialization / runtime story is simple. Static members are treated as if
they are restricted to the erased species (this is a natural choice, since
Class[Foo] and ParamType[Foo, erased] describe the same class.) __SS members
become static members on each parameterization. (Both of these are one-line
changes to the existing specializer prototype.) TypeVar constants used in the
signature / bodies of __SS members are specialized as usual, and just work.
Example:
class Collection<any T> {
private __SS Collection<T> emptyCollection = …
// ACC_SS field emptyCollection : ParamType[Collection, TypeVar[T]]
private __SS Collection<T> emptyCollection() { return emptyCollection; }
ACC_SS emptyCollection()ParamType[Collection, TypeVar[T]] {
getstatic ParamType[Collection, TypeVar[T]].emptyCollection :
ParamType[Collection, TypeVar[T]]]
areturn
}
When we specialize Collection<int>, the field type, method return type, etc,
will all collapse to Collection<int> by the existing mechanisms.
