<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" ><h1>Specialization statics</h1>
<h2>The problem</h2>
<div>In the old world, there are two possible member placements: static and instance. Static members have traditionally been described as “members on the class”, and we all assumed we understood what “class” meant. However, “class” is a heavily overloaded term, and it’s starting to crack, e.g. with generic specialization deriving multiple runtime types from a single class file.</div>
<div>The meaning of static may take on one of the following meanings in the new world:</div>
<ol>        <li>Per type – All specializations get their own static members.</li>        <li>Per class – All specializations share their static members.</li></ol>
<div>There are use cases for both 1 and 2.</div>
<div> </div>
<h2>Use cases</h2>
<h3>1. Type variable related statics</h3>
<div>In the old world, we knew that the erasure of a type variable was always its bound. This allowed us to create static members that would always be compatible with type variables, without referring to the type variable itself. For example:</div>
<div style="margin-bottom:.0001pt;" ><span style="font-family:consolas;" ><span style="font-size:11.0pt;" >class Foo<T> {</span></span></div>
<div style="margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:27.0pt;margin-bottom:.0001pt;" ><span style="font-family:consolas;" ><span style="font-size:11.0pt;" >static Object someT;</span></span></div>
<div style="margin-bottom:.0001pt;" ><span style="font-family:consolas;" ><span style="font-size:11.0pt;" >}</span></span></div>
<div>In this example, <span style="font-family:consolas;" >Object</span> is used instead of <span style="font-family:consolas;" >T</span>, because <span style="font-family:consolas;" >T</span> is not in the static scope. However, this is not possible when we introduce specialization, as we no longer have a common type for representing <span style="font-family:consolas;" >T</span>.</div>
<div>This pattern is seen in use cases like <span style="font-family:consolas;" >Collections.emptyList()</span>.</div>
<h3>2. Statics independent from type variables</h3>
<div>There are also cases where the static is not related to the type variable information. One example is an instance counter, which the user may want to treat as common for all specializations of a class.</div>
<div> </div>
<h2>Solutions</h2>
<div>Given that there are use case for both per-type and per-class static members, it appears that we need to support both member placements. Logically, there will be three places to put members:</div>
<ul>        <li>Class (all List)</li>        <li>Runtime type (all List<int>)</li>        <li>Instance (this List<int>)</li></ul>
<div>This can be implemented in different ways with varying levels of support from the Java compiler, the JVM, and the JDK.</div>
<h3>1. Library solution</h3>
<div>We can place the statics on the class, and implement specialization statics using a pattern similar to <span style="font-family:consolas;" >ClassValue</span>. The disadvantages are that it may have lower performance, it introduces more code changes when migrating to any-generics, and it is more complex to use in other JVM languages.</div>
<h3>2. New specialization static placement</h3>
<div>In this solution, we assume that specialization statics are not related to traditional class-wide statics. We fully embrace the new field placement, and support it both in the Java language and in the JVM. Specialization statics exist as its own set of members in the runtime type, and traditional statics continue to be class-wide. This will make the distinction between the different static types very clear, and it appears to be an acceptable solution. It does require an access flag on both fields and methods, but both have available bits.</div>
<div>The disadvantage is that it requires non-trivial JVM changes that would only be used by specialized types. The class structures in the JVM would have to represent the new placement as an additional set of fields. Getting, setting, and invoking these members requires additional bytecodes, which are a scarce resource.</div>
<h3>3. Repurpose existing statics</h3>
<div>In this solution, we assume that statics were in fact specialization statics all along; we just didn’t have specializations yet. The static placement will be used for specialization statics, and we specify a run-time type that will contain the static members we want to be common to all the specializations of a class. Currently, static members are always accessed on the raw type <span style="font-family:consolas;" >LFoo;</span>. Given that the raw type will be interpreted to mean the erased type, the erased type seems like the natural type to hold the class-wide static members.</div>
<div>Accessing a class-wide static member will look like this:</div>
<div style="margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:27.0pt;margin-bottom:.0001pt;" ><span style="font-family:consolas;" ><span style="font-size:11.0pt;" >class Foo<any T> {</span></span></div>
<div style="margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.75in;margin-bottom:.0001pt;" ><span style="font-family:consolas;" ><span style="font-size:11.0pt;" >static int i;</span></span></div>
<div style="margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.75in;margin-bottom:.0001pt;" ><span style="font-family:consolas;" ><span style="font-size:11.0pt;" >ACC_SPECIALIZED static int j;</span></span></div>
<div style="margin-left:27.0pt;" ><span style="font-family:consolas;" >}</span></div>
<div style="margin-left:27.0pt;" >Read <span style="font-family:consolas;" >i</span>:<br><span style="font-family:consolas;" >  getstatic Foo.i:I<br>  getstatic ParamType[Foo, erased].i:I</span></div>
<div style="margin-left:27.0pt;" >Read <span style="font-family:consolas;" >j</span>:<br><span style="font-family:consolas;" >  getstatic ParamType[Foo, T].j:I</span></div>
<div>The third placement still exists at the language level, and the compiler can use either conditional members or a new access flag to indicate when a static member is class wide. At the VM level, the access flag (or condition) is used by the specialization process to determine whether to include a static member in the current specialization.</div>
<div> </div>
<h2>Conclusion</h2>
<div>Describing static members as “members on the class” was a result of the fact there was no distinction between classes and run-time types. This lack of distinction also means that we can change the description of static members to “members on the type” without breaking the old world.</div>
<div>In order to support the old static pattern (i.e. class-wide) on new any-generic classes, the language will support a mechanism that moves per-class statics to the erased type.</div>
<div> </div></div>
<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" style="margin-top: 20px;" ><div style="font-size: 12pt; font-weight: bold; font-family: sans-serif; color: #7C7C5F;" ><div style="outline: none; color: rgb(41, 41, 41); font-family: Arial; font-size: 14px;" ><span style="outline: none; color: rgb(105, 105, 105);" ><span style="outline: none; font-size: 1.143em;" ><strong style="outline: none;" >Bjørn Vårdal</strong></span></span><br style="outline: none;" ><span style="outline: none; color: rgb(105, 105, 105);" >IBM Runtimes</span></div></div></div></div></div></div></div><BR>