<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" ><div dir="ltr" ><div dir="ltr" >I have a question about reifying array types. This is what I understand is the proposed behaviour:</div>
<ol dir="ltr" >        <li>Foo<String> - Reference, so erased</li>        <li>Foo<int> - Primitive, so reified</li>        <li>Foo<int[]> - In the Model 3 Classfile Design document, this is reified.</li>        <li>Foo<String[]> - Unclear - erased as reference, or reified as array?</li></ol>
<div dir="ltr" >The first two are quite clear, but I'm wondering about 3 and 4. What is the reason for reifying the int[] in the Model 3 document? Considering that both int[] and String are subclasses of Object, can we not erase array types? If we can't erase them, does that apply to reference arrays as well, e.g. String[]?</div></div></div>
<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" style="margin-top: 20px;" >--<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>Sent by: "valhalla-spec-experts" <valhalla-spec-experts-bounces@openjdk.java.net><br>To: valhalla-spec-experts@openjdk.java.net<br>Cc:<br>Subject: Model 3 classfile design document<br>Date: Fri, Jan 22, 2016 11:53 AM<br> 
<div><font face="Default Monospace,Courier New,Courier,monospace" size="2" >Please find a document here:<br><br><a href="http://cr.openjdk.java.net/~briangoetz/valhalla/eg-attachments/model3-01.html" target="_blank" >http://cr.openjdk.java.net/~briangoetz/valhalla/eg-attachments/model3-01.html</a><br><br>that describes our current thinking for evolving the classfile format to<br>clearly and efficiently represent parametric polymorphism.  The early<br>concepts of this approach were outlined in my talk at JVMLS last year;<br>this represents a refinement of those ideas, and a reasonable "stake in<br>the ground" description of what seems the most sensible way to balance<br>preserving parametric information in the classfile without imposing<br>excessive runtime costs for loading specializations.<br><br>We're working on an updated compiler prototype which people will be able<br>to play with soon (along with a formal model.)<br><br>Please ask questions!<br><br>Some things this document does not address yet:<br>  - How we deal with types implicit in the bytecodes (aload vs iload)<br>and how they get specialized;<br>  - How we represent restricted methods in the classfile;<br>  - How we represent the wildcard type Foo<any></font><br><br> </div></blockquote>
<div dir="ltr" > </div></div><BR>