<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi,<br>
    over the last few days I've been busy putting together a prototype
    [1, 2] of javac/runtime support for species static. I guess it could
    be considered an prototype implementation of the approach that Bjorn
    has described as "Repurpose existing statics" [4] in his nice
    writeup. Here's what I have learned during the experience.<br>
    <br>
    Parser<br>
    ====<br>
    <br>
    The prototype uses a no fuss approach where '__species' is the
    modifier to denote species static stuff (of course a better syntax
    will have to be picked at some point, but that's not the goal of the
    current exercise). This means you can write:<br>
    <br>
    <tt>class Foo<X> {</tt><tt><br>
    </tt><tt>   String i; //instance field</tt><tt><br>
    </tt><tt>   static String s; //static field</tt><tt><br>
    </tt><tt>   __species String ss; //species static field</tt><tt><br>
    </tt><tt>}</tt><br>
    <br>
    This is obviously good enough for the time being. <br>
    <br>
    A complication with parsing occurs when accessing species members;
    in fact, species members can be accessed via their fully qualified
    type (including all required type-arguments, if necessary).<br>
    <br>
    <tt>Foo<String>.ss;</tt><tt><br>
    </tt><tt>Foo<int>.ss;</tt><br>
    <br>
    The above are all valid species access expression. Now, adding this
    kind of support in the parser is always tricky - as we have to
    battle with ambiguities which might pop up. Luckily, this pattern is
    similar enough to the one we use for method references - i.e. :<br>
    <br>
    <tt>Foo<String>::ss</tt><br>
    <br>
    Which the compiler already had to special case; so I ended up
    slightly generalizing what we did in JDK 8 method reference parsing,
    and I got something working reasonably quick. But this could be an
    area where coming up with a clean spec might be tricky (as the impl
    uses abundant lookahead to disambiguate this one).<br>
    <br>
    Resolution<br>
    ======<br>
    <br>
    The basic idea is to divide the world in three static levels, whose
    properties are summarized in the table below:<br>
    <br>
    <table width="100%" cellpadding="2" cellspacing="2" border="1">
      <tbody>
        <tr>
          <td valign="top"><br>
          </td>
          <td valign="top">enclosing type<br>
          </td>
          <td valign="top">enclosing instance<br>
          </td>
        </tr>
        <tr>
          <td valign="top">instance<br>
          </td>
          <td valign="top">yes<br>
          </td>
          <td valign="top">yes<br>
          </td>
        </tr>
        <tr>
          <td valign="top">species<br>
          </td>
          <td valign="top">yes<br>
          </td>
          <td valign="top">no<br>
          </td>
        </tr>
        <tr>
          <td valign="top">static<br>
          </td>
          <td valign="top">no<br>
          </td>
          <td valign="top">no<br>
          </td>
        </tr>
      </tbody>
    </table>
    <br>
    So, in terms of who can access what, it follows that if we consider
    'instance' to be the highest static level and 'static' to be the
    lowest, then it's ok for a member with static level S1 to access
    another member of static level S2 provided that S1 >= S2. Or,
    with a table:<br>
    <br>
    <table width="100%" cellpadding="2" cellspacing="2" border="1">
      <tbody>
        <tr>
          <td valign="top">from/to<br>
          </td>
          <td valign="top">instance<br>
          </td>
          <td valign="top">species<br>
          </td>
          <td valign="top">static<br>
          </td>
        </tr>
        <tr>
          <td valign="top">instance<br>
          </td>
          <td valign="top">yes<br>
          </td>
          <td valign="top">yes<br>
          </td>
          <td valign="top">yes<br>
          </td>
        </tr>
        <tr>
          <td valign="top">species<br>
          </td>
          <td valign="top">no<br>
          </td>
          <td valign="top">yes<br>
          </td>
          <td valign="top">yes<br>
          </td>
        </tr>
        <tr>
          <td valign="top">static<br>
          </td>
          <td valign="top">no<br>
          </td>
          <td valign="top">no<br>
          </td>
          <td valign="top">yes<br>
          </td>
        </tr>
      </tbody>
    </table>
    <br>
    <br>
    So, let's look at a concrete example:<br>
    <br>
    <tt>class TestResolution {</tt><tt><br>
    </tt><tt>    static void m_S() {</tt><tt><br>
    </tt><tt>        m_S(); //ok</tt><tt><br>
    </tt><tt>        m_SS(); //error</tt><tt><br>
    </tt><tt>        m_I(); //error</tt><tt><br>
    </tt><tt>    }</tt><tt><br>
    </tt><tt><br>
    </tt><tt>    __species void m_SS() {         <br>
              m_S(); //ok<br>
              m_SS(); //ok</tt><tt><br>
    </tt><tt>        m_I(); //error     <br>
          }</tt><tt><br>
    </tt><tt>    <br>
          __species void m_I() {<br>
              m_S(); //ok<br>
              m_SS(); //ok<br>
              m_I(); //ok<br>
          }</tt><tt><br>
    </tt><tt>}</tt><br>
    <br>
    A crucial property, of course, is that species static members can
    reference to any type vars in the enclosing context:<br>
    <br>
    <tt>class TestTypeVar<X> {</tt><tt><br>
    </tt><tt>    static void m_S() {</tt><tt><br>
    </tt><tt>        X x; //error</tt><tt><br>
    </tt><tt>    }</tt><tt><br>
    </tt><tt><br>
    </tt><tt>    __species void m_SS() {<br>
               X x; //ok     <br>
          }</tt><tt><br>
    </tt><tt>    __species void m_I() {<br>
               X x; //ok<br>
          }</tt><tt><br>
    </tt><tt>}</tt><br>
    <br>
    Nesting<br>
    =====<br>
    <br>
    Another concept that needs generalization is that of allowed
    nesting; consider the following program:<br>
    <br>
    <tt>class TestNesting1 {</tt><tt><br>
    </tt><tt>    class MemberInner {</tt><tt><br>
    </tt><tt>        static String s_S; //error</tt><tt><br>
    </tt><tt>        String s_I; //ok</tt><tt><br>
    </tt><tt>    }</tt><tt><br>
    </tt><tt><br>
    </tt><tt>    static class StaticInner {</tt><tt><br>
    </tt><tt>         static String s_S; //ok</tt><tt><br>
    </tt><tt>         String s_I; //ok</tt><tt><br>
    </tt><tt>     }</tt><tt><br>
    </tt><tt>}</tt><tt><br>
    </tt><br>
    That is, the compiler will only allow you to declare static members
    in toplevel classes or in static nested classes (which, after all,
    act as toplevel classes). Now that we are adding a new static level
    to the picture, how are the nesting rules affected?<br>
    <br>
    Looking at the table above, if we consider 'instance' to be the
    highest static level and 'static' to be the lowest, then it's ok for
    a member with static level S1 to declare a member of static level S2
    provided that S1 <= S2. Again, we can look at this in a tabular
    fashion:<br>
    <br>
    <table width="100%" cellpadding="2" cellspacing="2" border="1">
      <tbody>
        <tr>
          <td valign="top">declaring/declared<br>
          </td>
          <td valign="top">instance<br>
          </td>
          <td valign="top">species<br>
          </td>
          <td valign="top">static<br>
          </td>
        </tr>
        <tr>
          <td valign="top">instance<br>
          </td>
          <td valign="top">yes<br>
          </td>
          <td valign="top">no<br>
          </td>
          <td valign="top">no<br>
          </td>
        </tr>
        <tr>
          <td valign="top">species<br>
          </td>
          <td valign="top">yes<br>
          </td>
          <td valign="top">yes<br>
          </td>
          <td valign="top">no<br>
          </td>
        </tr>
        <tr>
          <td valign="top">static<br>
          </td>
          <td valign="top">yes<br>
          </td>
          <td valign="top">yes<br>
          </td>
          <td valign="top">yes<br>
          </td>
        </tr>
      </tbody>
    </table>
    <br>
    This also seems like a nice generalization of the current rules. The
    rationale behind these rules is to  basically, guarantee some
    invariants during member lookup; let's say that we are in a nested
    class with static level S1 - then, by the rule above, it follows
    that any member nested in this class will be able to access another
    member with static level S1 declared in this class or in any
    lexically enclosing class.<br>
    <br>
    A full example of nesting rules is given below:<br>
    <br>
    <tt>class TestNesting2 {</tt><tt><br>
    </tt><tt>    class MemberInner {</tt><tt><br>
    </tt><tt>        static String s_S; //error</tt><tt><br>
              __species String s_SS; //error<br>
    </tt><tt>        String s_I; //ok</tt><tt><br>
    </tt><tt>    }</tt><tt><br>
      <br>
          </tt><br>
    <tt>    __species class StaticInner {</tt><tt><br>
    </tt><tt>         static String s_S; //error</tt><br>
    <tt><tt>        __species String s_SS; //ok</tt><tt><br>
      </tt> </tt><tt>         String s_I; //ok</tt><tt><br>
    </tt><tt>     }</tt><tt><br>
    </tt><tt><br>
    </tt><tt>    static class StaticInner {</tt><tt><br>
    </tt><tt>         static String s_S; //ok</tt><tt>        </tt><br>
    <tt><tt>        __species String s_SS; //ok</tt><tt><br>
      </tt> </tt><tt>         String s_I; //ok</tt><tt><br>
    </tt><tt>     }</tt><tt><br>
    </tt><tt>}</tt><tt><br>
    </tt><br>
    Unchecked access<br>
    ===========<br>
    <br>
    Because of an unfortunate interplay between species and erasure,
    code using species members is potentially unsound (the example below
    is a variation of an example first discovered by Peter's example [3]
    in this very mailing list):<br>
    <tt><br>
    </tt><tt>public class Foo<any T> {</tt><tt><br>
    </tt><tt>     __species T cache;</tt><tt><br>
    </tt><tt> }</tt><tt><br>
    </tt><tt> </tt><tt><br>
    </tt><tt> </tt><tt><br>
    </tt><tt>Foo<String>.cache = "Hello";<br>
      Integer i = Foo<Integer>.cache; //whoops<br>
    </tt><br>
    To prevent cases like these, the compiler implements a check which
    looks at the qualifier of a species access; if such qualifier
    (either explicit, or implicit) cannot be proven to be reifiable, an
    unchecked warning is issued.<br>
    <br>
    Note that it is possible to restrict such warnings only to cases
    where the signature of the accessed species static member changes
    under erasure. E.g. in the above example, accessing 'cache' is
    unchecked, because the type of 'cache' contains type-variables; but
    if another species static field was accessed whose type did not
    depend on type-variables, then the access should be considered
    sound.<br>
    <br>
    <br>
    Species initializers<br>
    ===========<br>
    <br>
    In our model we have three static levels - but we have
    initialization artifacts for only two of those; we need to fix that:<br>
    <br>
    <table width="100%" cellpadding="2" cellspacing="2" border="1">
      <tbody>
        <tr>
          <td valign="top">instance<br>
          </td>
          <td valign="top"><init><br>
          </td>
        </tr>
        <tr>
          <td valign="top">species<br>
          </td>
          <td valign="top"><sclinit><br>
          </td>
        </tr>
        <tr>
          <td valign="top">static<br>
          </td>
          <td valign="top"><clinit><br>
          </td>
        </tr>
      </tbody>
    </table>
    <br>
    <br>
    That is, a new <sclinit> method is added to a class containing
    one or more species variables with an initializer. This method is
    used to hoist the initialization code for all the species variables.<br>
    <br>
    Forward references<br>
    ============<br>
    <br>
    Rules for detecting forward references have to be extended
    accordingly. A forward reference occurs whenever there's an attempt
    to reference a variable from a position P, where the variable
    declaration occurs in a position P' > P. Currently, the rules for
    forward references allow an instance variable to forward-reference a
    static variable - as shown below:<br>
    <br>
    <tt>class TestForwardRef {</tt><tt><br>
    </tt><tt>    String s = s_S;</tt><tt><br>
    </tt><tt>    static String s_S = "Hello!";</tt><tt><br>
    </tt><tt> }</tt><br>
    <br>
    The rationale behind this is that, by the time we see the instance
    initializer for 's' we would have already executed the code for
    initializing 's_S' (as initialization will occur in different
    methods, <init> and <clinit> respectively, see section
    above). With the new static level, the forward reference rules have
    to be redefined according to the table below:<br>
    <br>
    <br>
    <table width="100%" cellpadding="2" cellspacing="2" border="1">
      <tbody>
        <tr>
          <td valign="top">from/to<br>
          </td>
          <td valign="top">instance<br>
          </td>
          <td valign="top">species<br>
          </td>
          <td valign="top">static<br>
          </td>
        </tr>
        <tr>
          <td valign="top">instance<br>
          </td>
          <td valign="top">forward ref<br>
          </td>
          <td valign="top">ok</td>
          <td valign="top">ok<br>
          </td>
        </tr>
        <tr>
          <td valign="top">species<br>
          </td>
          <td valign="top">illegal<br>
          </td>
          <td valign="top">forward ref<br>
          </td>
          <td valign="top">ok<br>
          </td>
        </tr>
        <tr>
          <td valign="top">static<br>
          </td>
          <td valign="top">illegal<br>
          </td>
          <td valign="top">illegal<br>
          </td>
          <td valign="top">forward ref<br>
          </td>
        </tr>
      </tbody>
    </table>
    <br>
    In other words, it's ok to forward reference a variable whose static
    level is lower than that available where the reference occurs. An
    example is given below:<br>
    <br>
    <tt>class TestForwardRef2 {</tt><tt><br>
    </tt><tt>    String s1_I = s_S; //ok</tt><tt><br>
    </tt><tt>   String s2_I = s_SS; //ok</tt><tt><br>
    </tt><tt><br>
    </tt><tt>   String s1_S = s_S; //error!</tt><tt><br>
    </tt><tt><br>
    </tt><tt>   String s1_SS = s_S; //ok</tt><tt><br>
    </tt><tt>   String s2_SS = s_SS; //error!</tt><tt><br>
    </tt><tt>    </tt><tt><br>
    </tt><tt>   </tt><tt>static String s_S = "Hello!";</tt><tt><br>
    </tt><tt>   __species String s_SS = "Hello Species!";</tt><tt><br>
    </tt><tt> }</tt><br>
    <br>
    This is an extension of the above principle: since instance
    variables are initialized in <init>, they can reference
    variables initialized in <clinit> or <sclinit>. If a
    variable is initialized in <sclinit> it can similarly safely
    reference a variable initialized in <clinit>. Another way to
    think of this is that a forward reference error only occurs if the
    static level of the referenced symbol is the same as the static
    level where the reference occurs. All other cases are either illegal
    (i.e. because it's an attempt to go from a lower static level to an
    higher one) or valid (because it can be guaranteed that the code
    initializing the referenced variable has already been executed).<br>
    <br>
    Code generation<br>
    ==========<br>
    <br>
    Javac currently emits invokestatic/getstatic/putstatic for both
    legacy static and species static access. javac will use the 'owner'
    field of a CONSTANT_MethodRef, CONSTANT_FieldRef constants to point
    to the sharp type of the species access (through a constant pool
    type entry). Static access will always see an erased owner.<br>
    <br>
    Consider this example:<br>
    <br>
    <tt>class TestGen<any X> {</tt><tt><br>
    </tt><tt>   __species void m_SS() { }</tt><tt><br>
    </tt><tt>   static void m_S() { }</tt><tt><br>
    </tt><tt><br>
    </tt><tt>   public static void main(String args) {</tt><tt><br>
    </tt><tt>       TestGen<String>.m_SS();</tt><tt><br>
    </tt><tt>       TestGen<int>.m_SS();</tt><tt><br>
    </tt><tt>       TestGen<String>.m_S();</tt><tt><br>
    </tt><tt>       TestGen<int>.m_S();</tt><tt><br>
    </tt><tt>   }</tt><tt><br>
    </tt><tt>}</tt><tt><br>
    </tt><br>
    The generated code in the 'main' method is reported below:<br>
    <br>
    <tt>0: invokestatic  #11                 // Method
      TestGen<_>.m_SS:()V</tt><tt><br>
    </tt><tt>3: invokestatic  #15                 // Method
      TestGen<I>.m_SS:()V</tt><tt><br>
    </tt><tt>6: invokestatic  #18                 // Method
      TestGen<_>.m_S:()V</tt><tt><br>
    </tt><tt>9: invokestatic  #18                 // Method
      TestGen<_>.m_S:()V</tt><br>
    <br>
    As it can be seen, species static access can cause a sharper type to
    end up in the 'owner' field of the member reference info; on the
    other hand, a static access always lead to an erased 'owner'.<br>
    <br>
    Another detail worth mentioning is how __species is represented in
    the bytecode. Given the current lack of flags bit I've opted to use
    the last remaining bit 0x8000 - this is in fact the last unused bit
    that can be shared across class, field and method descriptors.
    Actually, this bit has already been used to encode the ACC_MANDATED
    flag in the MethodParameters attribute (as of JDK 8) - but since
    there's no other usage of that flag configuration outside
    MethodParameters it would seem safe to recycle it. Of course more
    compact approaches are also possible, but they would lead to
    different flag configurations for species static fields, methods and
    classes.<br>
    <br>
    Specialization<br>
    =========<br>
    <br>
    Specializing species access is relatively straightforward:<br>
    <br>
    * both instance and species static members are copied in the
    specialization<br>
    * static members are only copied in the erased specialization (and
    skipped otherwise)<br>
    * ACC_SPECIES classes become regular classes when specialized<br>
    * ACC_SPECIES methods/fields become static methods/fields in the
    specialization<br>
    * <sclinit> becomes the new <clinit> in the
    specialization (and is omitted if the specialization is the erased
    specialization)<br>
    <br>
    The last bullet requires some extra care when handling the 'erased'
    specialization; consider the following example:<br>
    <br>
    <tt>class TestSpec<any X> {</tt><tt><br>
    </tt><tt>   static String s_S = "HelloStatic";</tt><tt><br>
    </tt><tt>   __species String s_SS = "HelloSpecies";</tt><tt><br>
    </tt><tt>}</tt><br>
    <br>
    This class will end up with the following two synthetic methods:<br>
    <br>
    <tt>static void <clinit>();</tt><tt><br>
    </tt><tt>    descriptor: ()V</tt><tt><br>
    </tt><tt>    flags: ACC_STATIC</tt><tt><br>
    </tt><tt>    Code:</tt><tt><br>
    </tt><tt>      stack=1, locals=0, args_size=0</tt><tt><br>
    </tt><tt>         0: ldc           #8                  // String
      HelloStatic</tt><tt><br>
    </tt><tt>         2: putstatic     #14                 // Field
      s_S:Ljava/lang/String;</tt><tt><br>
    </tt><tt>         5: ldc           #16                 // String
      HelloSpecies</tt><tt><br>
    </tt><tt>         7: putstatic     #19                 // Field
      s_SS:Ljava/lang/String;</tt><tt><br>
    </tt><tt>        10: return</tt><tt><br>
    </tt><tt><br>
    </tt><tt>  species void <sclinit>();</tt><tt><br>
    </tt><tt>    descriptor: ()V</tt><tt><br>
    </tt><tt>    flags: ACC_SPECIES</tt><tt><br>
    </tt><tt>    Code:</tt><tt><br>
    </tt><tt>      stack=1, locals=1, args_size=1</tt><tt><br>
    </tt><tt>         0: ldc           #16                 // String
      HelloSpecies</tt><tt><br>
    </tt><tt>         2: putstatic     #19                 // Field
      s_SS:Ljava/lang/String;</tt><tt><br>
    </tt><tt>         5: return</tt><br>
    <br>
    As it can be seen, the <clinit> method contains initialization
    code for both static and species static fields! To understand why
    this is so, let's consider how the specialized bits might be derived
    from the template class following the rules above. Let's consider a
    specialization like TestSpec<int>: in this case, we need to
    drop <clinit> (it's a static method and TestSpec<int> is
    not an erased specialization), and we also need to rename
    <sclinit> as <clinit> in the new specialization. All is
    fine - the specialization will contain the relevant code required to
    initialize its species static fields.<br>
    <br>
    Let's now turn to the erased specialization TestSpec<_> - this
    specialization receives both static and species static members. Now,
    if we were to follow the same rules for initializers, we'd end up
    with two different initializer methods - both <clinit> and
    <sclinit>. We could ask the specializer to merge them somehow,
    but that would be tricky and expensive. Instead, we simply (i) drop
    <sclinit> from the erased specialization and (ii) retain
    <clinit>. Of course this means that <clinit> must also
    contain initialization code for species static members.<br>
    <br>
    Bonus point: Generic methods<br>
    ===================<br>
    <br>
    As pointed out by Brian, if we have species static classes we can
    translate static and species static specializable generic methods
    quite effectively. Consider this example:<br>
    <br>
    <tt>class TestGenMethods {</tt><tt><br>
    </tt><tt>   static <any X> void m(X x) { ... }</tt><tt><br>
    </tt><tt><br>
    </tt><tt>   void test() {</tt><tt><br>
    </tt><tt>       m(42);</tt><tt><br>
    </tt><tt>   }</tt><tt><br>
    </tt><tt>}</tt><br>
    <br>
    without species static, this would translate to:<br>
    <br>
    <tt>class TestGenMethods {</tt><tt><br>
    </tt><tt>    static class TestGenMethods$m<any X> {</tt><tt><br>
    </tt><tt>         void m(X z) { ... }</tt><tt><br>
    </tt><tt>    }</tt><tt><br>
    </tt><tt><br>
    </tt><tt>    /* bridge */ void m(Object o) { new
      TestGenMethods$m().m(o); }</tt><tt><br>
    </tt><tt><br>
    </tt><tt>    void test() {</tt><tt><br>
    </tt><tt>        new TestGenMethod$m<int>().m(42); // this is
      really done inside the BSM</tt><tt><br>
    </tt><tt>    }</tt><tt><br>
    </tt><tt>}</tt><br>
    <br>
    Note how the bridge (called by legacy code) will need to spin a new
    instance of the synthetic class and then call a method on it. The
    bootstrap used to dispatch static generic specializable calls also
    needs to do a very similar operation. But what if we turned the
    translated generic method into a species static method?<br>
    <br>
    <tt>class TestGenMethods {</tt><tt><br>
    </tt><tt>     class TestGenMethods$m<any X> {</tt><tt><br>
    </tt><tt>          __species void m(X z) { ... }</tt><tt><br>
    </tt><tt>     }</tt><tt><br>
    </tt><tt> </tt><tt><br>
    </tt><tt>     /* bridge */ void m(Object o) { TestGenMethods$m.m(o);
      }</tt><tt><br>
    </tt><tt><br>
    </tt><tt>    void test() {</tt><tt><br>
    </tt><tt>         TestGenMethod$m<int>.m(42); // this is
      really done inside the BSM</tt><tt><br>
    </tt><tt>     }</tt><tt><br>
    </tt><tt> }</tt><br>
    <br>
    With species static, we can now access the method w/o needing any
    extra instance. This leads to simplification in both the bridging
    strategy and the bootstrap implementation. We can apply a similar
    simplification for dispatch of specializable species static calls -
    the only difference is that the synthetic holder class has also to
    be marked as species static (since it could access type-vars from
    the enclosing context).<br>
    <br>
    Bonus point: Access bridges<br>
    =================<br>
    <br>
    Access bridges are a constant pain in the current translation
    strategy; such bridges are generated by the compiler to grant access
    to otherwise inaccessible members. Example:<br>
    <br>
    <tt>class Outer<any X> {</tt><tt><br>
    </tt><tt>    private void m() { }</tt><tt><br>
    </tt><tt><br>
    </tt><tt>    class Inner {</tt><tt><br>
    </tt><tt>        void test() {</tt><tt><br>
    </tt><tt>            m();</tt><tt><br>
    </tt><tt>        }</tt><tt><br>
    </tt><tt>    }</tt><tt><br>
    </tt><tt>}</tt><tt><br>
    </tt><br>
    This code will be translated as follows:<br>
    <br>
    <tt>class Outer<any X> {</tt><tt><br>
    </tt><tt><br>
    </tt><tt>    /* synthetic */ static access$m(Outer o) { o.m(); }</tt><tt><br>
    </tt><tt><br>
    </tt><tt>     private void m() { }</tt><tt><br>
    </tt><tt> </tt><tt><br>
    </tt><tt>     class Inner {</tt><tt><br>
    </tt><tt>        /*synthetic*/ Outer this$0;</tt><tt><br>
    </tt><tt><br>
    </tt><tt>         void test() {</tt><tt><br>
    </tt><tt>             access$m(this$0);</tt><tt><br>
    </tt><tt>         }</tt><tt><br>
    </tt><tt>     }</tt><tt><br>
    </tt><tt> }</tt><br>
    <br>
    That is, access to private members is translated with an access to
    an accessor bridge, which then performs access from the right
    location. Note that the accessor bridge is static (because otherwise
    it would be possible to maliciously override it to grant access to
    otherwise inaccessible members); since it's static, usual rules
    apply, so it cannot refer to type-variables, it cannot be
    specialized, etc. This means that there are cases with
    specialization where existing access bridge are not enough to
    guarantee access - if the access happens to cross specialization
    boundaries (i.e. accessing m() from an Outer<int>.Inner).<br>
    <br>
    Again, species static comes to the rescue:<br>
    <br>
    <tt>class Outer<any X> {</tt><tt><br>
    </tt><tt> </tt><tt><br>
    </tt><tt>     /* synthetic */ __species access$m(Outer<X> o) {
      o.m(); }</tt><tt><br>
    </tt><tt> </tt><tt><br>
    </tt><tt>     private void m() { }</tt><tt><br>
    </tt><tt> </tt><tt><br>
    </tt><tt>     class Inner {</tt><tt><br>
    </tt><tt>         /*synthetic*/ Outer this$0;</tt><tt><br>
    </tt><tt> </tt><tt><br>
    </tt><tt>         void test() {</tt><tt><br>
    </tt><tt>             Outer<X>.access$m(this$0);</tt><tt><br>
    </tt><tt>         }</tt><tt><br>
    </tt><tt>     }</tt><tt><br>
    </tt><tt> }</tt><br>
    <br>
    Since the accessor bridge is now species static, it means it can now
    mention type variables (such as X); and it also means that when the
    bridge is accessed (from Inner), the qualifier type (Outer<X>)
    is guaranteed to remain sharp from the source code to the bytecode -
    which means that when this code will get specialized, all references
    to X will be dealt with accordingly (and the right accessor bridge
    will be accessed).<br>
    <br>
    Parting thoughts<br>
    ==========<br>
    <br>
    On many levels, species statics seem to be the missing ingredient
    for implementing many of the tricks of our translation strategy, as
    well as to make it easier to express common idioms (i.e.
    type-dependent caches) in user code.<br>
    <br>
    Adding support for species static has proven to be harder than
    originally thought. This is mainly because the current world is
    split in two static levels: static and instance. When something is
    not static it's implicitly assumed to be instance, and viceversa. If
    we add a third static level to the picture, a lot of the existing
    code just doesn't work anymore, or has to be validated to check as
    to whether 'static' means 'legacy static' or 'species static' (or
    both).<br>
    <br>
    I started the implementation by treating static, species static and
    instance as completely separate static levels - with different
    internal flags, etc. but I soon realized that, while clean, this
    approach was invalidating too much of the existing implementation.
    More specifically, all the code snippets checking for static would
    now have been updated to check for static OR species static
    (overriding vs. hiding, access to 'this', access to 'super', generic
    bridges, ...). On the other hand, the places where the semantics of
    species static vs. static was different were quite limited:<br>
    <br>
    * membership/type substitution: a species static behaves like an
    instance member; the type variables of the owner are replaced into
    the member signature.<br>
    * resolution: we need to implement the correct access rules as shown
    in the tables above.<br>
    * code generation: an invokestatic involving a species static gets a
    sharp qualifier type<br>
    <br>
    This quickly led to the realization that it was instead easier to
    just treat 'species static' as a special case of 'static' - and then
    to add finer grained logic whenever we really needed the
    distinction. This led to a considerably easier patch, and I think
    that a similar consideration will hold for the JLS.<br>
    <br>
    [1] - <a class="moz-txt-link-freetext"
href="http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/6949c3d06e8f">http://hg.openjdk.java.net/valhalla/valhalla/langtools/rev/6949c3d06e8f</a><br>
    [2] - <a class="moz-txt-link-freetext"
      href="http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/836efde938c1">http://hg.openjdk.java.net/valhalla/valhalla/jdk/rev/836efde938c1</a><br>
    [3] -
    <a class="moz-txt-link-freetext"
href="http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2016-February/000096.html">http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2016-February/000096.html</a><br>
    [4] -
<a class="moz-txt-link-freetext" href="http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2016-May/000147.html">http://mail.openjdk.java.net/pipermail/valhalla-spec-experts/2016-May/000147.html</a><br>
    <br>
    Maurizio<br>
    <br>
    <br>
    <br>
  </body>
</html>