<!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 2 Jul 2022, at 20:24, John Rose wrote:</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;">
<p dir="auto">…<br>
<a href="http://cr.openjdk.java.net/~jrose/values/encapsulating-val.md" style="color: #777777;">http://cr.openjdk.java.net/~jrose/values/encapsulating-val.md</a><br>
<a href="http://cr.openjdk.java.net/~jrose/values/encapsulating-val.html" style="color: #777777;">http://cr.openjdk.java.net/~jrose/values/encapsulating-val.html</a></p>
</blockquote>
<p dir="auto">On 3 Jul 2022, at 5:25, Remi Forax wrote:</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;">
<p dir="auto">…<br>
One kind of sad thing with CONSTANT_Class QC; is that we need it now but once we will have the new generics, we will not need it anymore because it can be express with a CONSTANT_Specialization_Linkage + a constant dynamic. So it's a kind of temporary design.</p>
</blockquote>
<p dir="auto">That’s probably true. But (like you?) I think this “sad thing” is too hard to avoid. One consolation: The existing descriptor syntax for a CONSTANT_Class of an <em>array type</em> is much older sad thing of the same type. The two sad things can keep each other company in a corner of the JVMS.</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;">
<p dir="auto">I wonder if it's not "better" to separate checkcast from unbox/box given that mixing them together result in different resolution for all checkcasts (compare to anewarray). From the language POV, those two kind of checkcasts are different anyway.</p>
</blockquote>
<p dir="auto">But from the JVM POV lumping behaviors into bytecodes is a much better move, than splitting them out into separate new bytecodes, when the lumping makes any sense at all. And in this case it does.</p>
<p dir="auto">On 4 Jul 2022, at 6:45, Dan Heidinga wrote:</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;">
<p dir="auto">Sorry for top-posting but it was easier to track a list of issues as I<br>
read through:</p>
</blockquote>
<p dir="auto">I actually prefer the top-posting, and the markdown is kind of a mess, so you don’t need to apologize. :-)</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;">
<ul>
<li>Miscellaneous privatization checks</li>
</ul>
<p dir="auto">--> MethodHandle.asType(MT) and MethodHandle.invoke() will also need<br>
to protect against the zero being introduced.<br>
…Here we see invoke() converting a void to a reference (null) and<br>
similarly for a primitive, to zero. Both these apis will need similar<br>
treatment as ::explictCastArguments.</p>
</blockquote>
<p dir="auto">Good catch. I see you still remember your JSR 292 details. Fixed.</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;">
<p dir="auto">Serialization<br>
--> There's a mention of serialization but if Lambda taught us<br>
anything, it's that serialization requires more thought than we<br>
expected, even if we take that into account =) We should spend some<br>
time on what serialization of a C.val actually means, any format<br>
concerns, and how it interacts with default reconstitution behaviours.<br>
Otherwise, we'll leave a hole here where unconstructed values can be<br>
deserialized.</p>
</blockquote>
<p dir="auto">Added this:</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;">
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; border-left-color: #999999; color: #999999;">
<p dir="auto">Reconstruction operations defined outside of <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C</code> must be designed with<br>
great care if they use elevated privileges beyond what <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C</code> provides<br>
directly. Given the historically tricky nature of deserialization,<br>
more work is needed to consider what serialization of a C.val actually<br>
means and how it interacts with default reconstitution behaviours.<br>
One likely possibility is that wire formats should only work with<br>
<code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.ref</code> types with proper construction paths (enforced by serialization),<br>
and leave conversion to <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.val</code> types to deserialization code inside<br>
the encapsulation of <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C</code>.</p>
</blockquote>
</blockquote>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;">
<p dir="auto">C.default & Reflection<br>
--> Is "default" a reflectively accessible field or compiler sugar?<br>
If a user does C.val.class.getDeclaredFields will it find "default"?<br>
Or maybe C.class.getDeclaredFields? I'm fine with it being a fiction<br>
but I wasn't clear how far we were pushing that into the reflective<br>
model as well. I think the intent is to expose this with<br>
Class::defaultValue / Lookup::defaultValue APIs but clarification<br>
would be good.</p>
<p dir="auto">Accessing C.val.class<br>
--> Do we need restrictions here beyond those of accessing C.class?</p>
</blockquote>
<p dir="auto">Those restrictions are a paper tiger, as I think I’ve proven. My recommendation is to have a second paper tiger on <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.val.class</code> as well. This consistency has a specific goal, to help users learn more quickly how access control of <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.val</code> works, giving them direct experience with it via the <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.val.class</code> syntax.</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;">
<p dir="auto">The mirror may be required to create MethodTypes for use in<br>
MethodHandle lookup().find* apis even by code that can't create a<br>
C.val. Given that it will leak already as shown in the doc, do we<br>
need the extra restrictions?</p>
</blockquote>
<p dir="auto">It’s a paper tiger, but an educational one.</p>
</div></div></body>
</html>