<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 <brian.goetz@oracle.com><br>To: Bjorn B Vardal/Ottawa/IBM@IBMCA, valhalla-spec-experts@openjdk.java.net<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>