<div dir="ltr">A question about these examples:<div><ul style="color:rgb(0,0,0);font-family:'Bitstream Vera Sans',Verdana,'sans serif';font-size:medium;line-height:normal"><li style="margin:0ex 0em;list-style-type:square">R(<code style="white-space:pre;font-family:'courier new',monospace;font-weight:bold">Foo<raw></code>) = <code style="white-space:pre;font-family:'courier new',monospace;font-weight:bold">Class["Foo"]</code> or <code style="white-space:pre;font-family:'courier new',monospace;font-weight:bold">ParameterizedType['L', "Foo", "_"]</code></li><li style="margin:0ex 0em;list-style-type:square">R(<code style="white-space:pre;font-family:'courier new',monospace;font-weight:bold">Foo<String></code>) = <code style="white-space:pre;font-family:'courier new',monospace;font-weight:bold">Class["Foo"]</code> or<code style="white-space:pre;font-family:'courier new',monospace;font-weight:bold">ParameterizedType['L', "Foo", "_"]</code></li><li style="margin:0ex 0em;list-style-type:square">R(<code style="white-space:pre;font-family:'courier new',monospace;font-weight:bold">Foo<int[]></code>) =<code style="white-space:pre;font-family:'courier new',monospace;font-weight:bold">ParameterizedType['L', "Foo", ArrayType[1, "I"]]</code><br></li></ul>Apparently, we want to preserve the information about int[], while we don't care about String. Why? Isn't int[] just a class, like String?</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 22, 2016 at 7:53 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Please find a document here:<br>
<br>
<a href="http://cr.openjdk.java.net/~briangoetz/valhalla/eg-attachments/model3-01.html" rel="noreferrer" 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><br>
<br>
<br>
</blockquote></div><div dir="ltr">-- <br></div><div dir="ltr"><div>Andrey Breslav</div><div>Project Lead of Kotlin</div><div>JetBrains</div><div><a href="http://kotlinlang.org/">http://kotlinlang.org/</a><br></div><div><div>The Drive to Develop</div></div></div>