<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <tt>It's possible that there could be multiple "ssinit" methods,
      each restricted to specific parameterizations (just like any other
      restricted method), but in general, the "ssinit" method can be
      specialized just like any other method.  So what I envision (in
      the absence of initialization of conditional members) is possibly
      two such methods; one that is specializable (corresponding to _SS
      members) and one that is not, restricted to the erased
      parameterization (corresponding to traditional statics.)<br>
      <br>
      <br>
    </tt><br>
    <div class="moz-cite-prefix">On 2/22/2016 4:11 PM, Bjorn B Vardal
      wrote:<br>
    </div>
    <blockquote
      cite="mid:201602222111.u1MLBcpn021902@d03av01.boulder.ibm.com"
      type="cite">
      <div class="socmaildefaultfont" dir="ltr"
        style="font-family:Arial;font-size:10.5pt">
        <div dir="ltr" style="font-family:Arial;font-size:10.5pt">
          <div dir="ltr">
            <div dir="ltr">
              <div>I think we're on the same page regarding specialized
                <clinit>.</div>
              <div> - The JVM will be handed multiple <clinit>
                partial methods, and the specializer will take care of
                selecting the appropriate <clinit> for each
                specialization.</div>
              <div> - The erased <clinit> will contain the
                non-specialized static initialization code, which
                ensures that it only runs once.</div>
              <div> - The erased <clinit> will always run before
                the first specialization <clinit>.</div>
              <div> - The Java syntax is still up for discussion.</div>
              <div> </div>
              <div> </div>
              <div>> I think this is mostly a matter of coming up
                with the right syntax, which makes it clear that statics
                can be per-class or per-specialization.  There are a
                whole pile of related specialization-related syntax
                issues, I'll try to get them all in one place.</div>
              <div> </div>
            </div>
            <div dir="ltr">I don't think the problem will be to make it
              clear that statics can be per-class or per-specialization,
              but rather why some parameterizations (which to the user
              are synonymous with specializations) don't appear to have
              specialized statics. Do we want to put erasure in the face
              of users like this? It seems better to let the users deal
              purely with parameterizations, and we let specialization
              and erasure be implementation details.</div>
            <div dir="ltr"> </div>
            <div dir="ltr">--<br>
              Bjørn Vårdal</div>
          </div>
          <div dir="ltr"> </div>
          <div dir="ltr"> </div>
          <blockquote data-history-content-modified="1" dir="ltr"
            style="border-left:solid #aaaaaa 2px; margin-left:5px;
            padding-left:5px; direction:ltr; margin-right:0px">-----
            Original message -----<br>
            From: Brian Goetz <a class="moz-txt-link-rfc2396E" href="mailto:brian.goetz@oracle.com"><brian.goetz@oracle.com></a><br>
            To: Bjorn B Vardal/Ottawa/IBM@IBMCA,
            <a class="moz-txt-link-abbreviated" href="mailto:valhalla-spec-experts@openjdk.java.net">valhalla-spec-experts@openjdk.java.net</a><br>
            Cc:<br>
            Subject: Re: Classes, specializations, and statics<br>
            Date: Thu, Feb 18, 2016 7:55 PM<br>
             <br>
            <!--Notes ACF
<meta content="text/html; charset=utf8" http-equiv="Content-Type" >--><br>
             
            <blockquote
              cite="mid:201602182155.u1ILtbE6013161@d01av03.pok.ibm.com"
              type="cite">
              <div dir="ltr" style="font-family:Arial;font-size:10.5pt">
                <div dir="ltr">
                  <div dir="ltr">
                    <div dir="ltr">Based on the example above, I think
                      we need to be more explicit about how the
                      <clinit> method is handled.</div>
                  </div>
                  <div dir="ltr"> </div>
                  <div dir="ltr">There are really two different sets of
                    statics that need to be handled by the class
                    initialization: </div>
                  <div dir="ltr">A) common statics (shared across all
                    instantiations)</div>
                  <div dir="ltr">B) specialized statics</div>
                  <div dir="ltr">In addition to the statics, there is
                    also common (and maybe specialized?) code that is
                    run as part of <clinit>.</div>
                </div>
              </div>
            </blockquote>
            <br>
            There is a reasonable model to collapse these back into one
            concept; treat "common statics" as specialized statics on
            the all-erased parameterization, with a <where> clause
            that restricts them to that parameterization.  Not clear
            whether we actually want to represent it that way or not,
            but its a useful mental model that doesn't require the
            creation of a third thing.  (Since Class[Foo] and
            ParamType[Foo,erased*] describe the same class, this is also
            fully binary compatible with existing classes.) <br>
            <br>
            Which means we can do a similar thing with <clinit>,
            if we want.  I'll wave my hands because we've not yet talked
            much about conditional members, but it basically looks like
            this:<br>
            <br>
            <where T*=erased*><br>
            <init>() { /* common static init code */<br>
                           /* specializable init code */ }<br>
            <br>
            <init>() { /* specializable init code */ }<br>
            <br>
            Or not. <br>
             
            <blockquote
              cite="mid:201602182155.u1ILtbE6013161@d01av03.pok.ibm.com"
              type="cite">
              <div dir="ltr" style="font-family:Arial;font-size:10.5pt">
                <div dir="ltr">
                  <div dir="ltr"> </div>
                  Where will the initialization code for both kinds of
                  statics be?  The existing <clinit> method?</div>
              </div>
            </blockquote>
            <br>
            We have two choices:<br>
             - have a new <sclinit> block that gets run once per
            specialization, and keep <clinit><br>
             - merge the two as above, exploiting planned support for
            conditional members<br>
            <br>
            Either way, as you say, we have to ensure that the common
            init runs exactly once. <br>
             
            <blockquote
              cite="mid:201602182155.u1ILtbE6013161@d01av03.pok.ibm.com"
              type="cite">
              <div dir="ltr" style="font-family:Arial;font-size:10.5pt">
                <div dir="ltr"> 
                  <div dir="ltr">When using *static, are we only
                    discussing {get,put}?  Or is this also proposing
                    invokestatic changes to allow specialized static
                    methods?</div>
                </div>
              </div>
            </blockquote>
            <br>
            Methods too.<br>
             
            <blockquote
              cite="mid:201602182155.u1ILtbE6013161@d01av03.pok.ibm.com"
              type="cite">
              <div dir="ltr" style="font-family:Arial;font-size:10.5pt">
                <div dir="ltr">
                  <div dir="ltr"> </div>
                  All of the technical details aside, is this something
                  we really want to expose to the users?  They're going
                  to have a hard time understanding why Foo<int>
                  (or Foo<ValueType) gets specialized statics while
                  Foo<String> & Foo<Bar> share the
                  erased version.</div>
              </div>
            </blockquote>
            <br>
            I think this is mostly a matter of coming up with the right
            syntax, which makes it clear that statics can be per-class
            or per-specialization.  There are a whole pile of related
            specialization-related syntax issues, I'll try to get them
            all in one place. <br>
            <br>
             </blockquote>
          <div dir="ltr"> </div>
        </div>
      </div>
      <br>
    </blockquote>
    <br>
  </body>
</html>