<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body><div style="font-family: sans-serif;"><div class="markdown" style="white-space: normal;">
<p dir="auto">On 18 Jul 2022, at 18:18, Remi Forax wrote:</p>
</div><div class="plaintext" style="white-space: normal;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;"><p dir="auto">I've just finished to re-read the document.</p>
</blockquote></div>
<div class="markdown" style="white-space: normal;">
<p dir="auto">Thank you!</p>
</div><div class="plaintext" style="white-space: normal;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;"><p dir="auto">- There is an issue with Collections.toArray(), this is not well known but toArray(array) add a null isf the array is bigger than the collection size, so if array is an array of C.val i suppose that a default value can be inserted.
<br>
from the javadoc "If this collection fits in the specified array with room to spare (i.e., the array has more elements than this collection), the element in the array immediately following the end of the collection is set to null . (This is useful in determining the length of this collection only if the caller knows that this collection does not contain any null elements.) "</p>
</blockquote></div>
<div class="markdown" style="white-space: normal;">
<p dir="auto">By my reading of that spec, adding <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">null</code> cannot materialize <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.default</code>, but rather must cause a NPE, which is the normal result of storing a null into a val-array. (Non-ref arrays never contain <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">null</code>!) This will be true regardless of privatization of <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.val</code>.</p>
</div><div class="plaintext" style="white-space: normal;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;"><p dir="auto">- Do we agree that this document prohibits to create an ArrayList of C.val (or any collections of C.val) if C.val is declared private or package private once the generics are updated (anewarray/aconst_init of C.val will fail at runtime) ?</p>
</blockquote></div>
<div class="markdown" style="white-space: normal;">
<p dir="auto">That depends on translation strategy for updated generics. If updated generics are still erased, then yes. If we go to the PVM and specialized generics, then the TS will surely provide the specialization engine with a <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">Lookup</code> for the client asking for <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">ArrayList<C.val></code>, and can check if that client can really access <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.val</code>.</p>
<p dir="auto">Next, if <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">ArrayList.java</code> has been recoded appropriately (whatever that means, in the end), surely whatever stands for <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">new T[n]</code> in the code will be able to access the capability of building the array by delegating through the specialization anchor (which can hold a <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">Lookup</code> if the TS sets that up).</p>
<p dir="auto">Maybe the language will allow a real literal <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">new T[n]</code>, or maybe <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">ArrayList.java</code> has to use some hocus-pocus with method handles. I can’t predict details but I am confident that these issues can be handled above the level of the PVM in the bootstrap methods and translation strategy.</p>
</div><div class="plaintext" style="white-space: normal;"><blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;"><p dir="auto">This seems too restrictive to me. It should be possible to create an array of T with T a C.val at runtime but it should not be possible to create a C.val out of thin air.</p>
</blockquote></div>
<div class="markdown" style="white-space: normal;">
<p dir="auto">I agree. One of the challenges of the JLS support for specialized generics will be deciding how to permit delegation of the permission to do <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">new C.val[n]</code> in generic code under the guise <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">new T[n]</code> (or some equivalent expression), when <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">T</code> is <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.val</code> and <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.val</code> is privatized. It seems clear that some provision should be made.</p>
<p dir="auto">When I make a specialized generic <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">Foo<C.val></code> or <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">Foo<C.val>::m</code> and <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.val</code> is privatized, (a) <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.val</code> is access-checked to me, but (b) I am entrusting its use to the generic as well. If (b) is not true I should be saying <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">Foo<C></code> instead.</p>
<p dir="auto">…That raises the question, for specialized generics, whether the related but distinct access checks on the <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C</code> name should be done (as well as for privatized <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.val</code>). I guess they should, but this is somewhat incompatible with erased generics. For erased generics, I can say <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">List<MyPrivateClass></code> and it all works, because the erased generic code can never see <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">MyPrivateClass</code>. If we try that with specialized generics, then there are a number of choices:</p>
<ul>
<li>
<p dir="auto">Delegate access to <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">MyPrivateClass</code> to the specialized generic (via the specialization anchor and a <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">Lookup</code> if necessary).</p>
</li>
<li>
<p dir="auto">Refuse to build the specialization at link-time unless everybody has access to <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">MyPrivateClass</code>. (The BSM for the specialization performs an access check to <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">MyPrivateClass</code> from both the specialized generic code and from the <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">Lookup</code> of the client.)</p>
</li>
<li>
<p dir="auto">Build the specialization but throw an error when the specialized code tries to do something that would be an access failure in written-out code. (Yuck, late failures!)</p>
</li>
<li>
<p dir="auto">In the BSM check access to <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">MyPrivateClass</code> to the caller, and give the specialized code carte blanche to do whatever with it. (This means I can write generics that can “grab” secure capabilities from type args.)</p>
</li>
<li>
<p dir="auto">In the BSM check access to <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">MyPrivateClass</code> to both caller and generic code (as before) and if either fails, fallback to use erasure.</p>
</li>
</ul>
<p dir="auto">This is the sort of thing the PVM won’t care about… but the JLS and TS (with its BSM support) will have to figure it all out.</p>
</div></div></body>
</html>