<div dir="ltr">Some additional comments based on my read through.<div><br></div><div>4.4.8 The CONSTANT_MethodHandle_info Structure<br>> Design discussion: the withfield and aconst_init instructions may justify new forms of CONSTANT_MethodHandle, but for now no changes are made to reference_kind.<br><br>Both instructions need to be incorporated in a method and carry nest-restrictions.  I don't think we want to reify these instructions as new MH types.  Better to rely on the programmers intent and have programmers opt to expose this functionality through methods.<br><br>4.4.10 The CONSTANT_Dynamic_info and CONSTANT_InvokeDynamic_info Structures<br>> We could allow <vnew> here, but the precedent seems to be to avoid any special method names when using invokedynamic.<br><br>Agreed on not allowing special names in invokedynamic.<br><br>4.6 Methods<br>> A method of an abstract class, an identity class, or an interface must not have the name <vnew>.<br>and <br>> If the name of the method is <vnew>, then the descriptor must denote a return type that is the type of the current class or interface.<br><br>We had previously discussed this restriction and I thought we mostly agreed on dropping it as each previous discussion didn't result in a clear answer on the value of the restriction.  The intention to allow reflection to use the return type to treat <vnew> methods as j.l.r.Constructor objects would violate the invariant that a constructor returns an instance of the declaring class.  Here we don't have to do that (and can also return null) so it would weaken the guarantees provided by Constructor and lead to programmer errors as they aren't used to validating Constructors previous invariants (which vnew can violate).<br><br>I'm also unsure how to read that last clause "... type of the current class or interface."  I'm interpreting it as "current class or *an* interface" as <nvew> isn't allowed in interfaces so it can't be "current interface". Is the intention that the VM loads any class named as the return type in a <vnew> method descriptor to enforce it is an interface?<br><br>Preload<br>-- need definition of when loading occurs.  This should be added to section 5.3.5 to outline when the Preloaded classes are made available. Because this is observable behaviour, we should mandate when it occurs.  Or at least it will occur before stage X.<br><br>6.5 Instructions<br>> aconst_init<br>> The referenced value class is initialized if it has not already been initialized (5.5).<br><br>I think we have some missing cases around value class initialization that I think we've talked about previously but I don't see here. Basically, any Array creation would need to ensure the class is initalized as well as would static fields of value classes.<br><br>Since we're talking about having two classes - the reference class and the value companion - we should be clear in the spec on how class loading & initalization for this works.  Given the companion<br>class is derived from the ValueClass attribute in the reference's classfile, the spec should indicate that the reference projection is loaded first, then the value companion.  And that the value companion, not being a true class, doesn't get its own <clinit>?  Another option here is to hide this distinction in the translation layer so you can't ask "Class.forName("Point.val")" and need to instead do a "Class.forName("Point").valueClass()". <br><br>I think we've under-specified this interaction so far and need to add more text to cover how the two j.l.Class objects relate and how that hooks into VM-lifecycle events like class loading and initialization.<br><br>Also the "ValueClass" attribute proposed in John's "Value type companions, encapsulated" email from July 3, 2022 seems to be missing from this draft.<br></div><div><br></div><div>--Dan</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 31, 2022 at 11:49 AM John Rose <<a href="mailto:john.r.rose@oracle.com">john.r.rose@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>


<div><div style="font-family:sans-serif"><div style="white-space:normal">
</div><div style="white-space:normal"><blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(119,119,119);color:rgb(119,119,119)"><p dir="auto"><a href="http://cr.openjdk.java.net/~dlsmith/jep8277163/latest" style="color:rgb(119,119,119)" target="_blank">http://cr.openjdk.java.net/~dlsmith/jep8277163/latest</a></p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">I edited the URL to find the corresponding JVMS updates:</p>
<p dir="auto"><a href="http://cr.openjdk.java.net/~dlsmith/jep8277163/jep8277163-20220830/specs/value-objects-jvms.html" style="color:rgb(57,131,196)" target="_blank">http://cr.openjdk.java.net/~dlsmith/jep8277163/jep8277163-20220830/specs/value-objects-jvms.html</a></p>
<p dir="auto">I have a few unsystematic comments on the special subject of special methods.</p>
<p dir="auto">In that draft JVMS, we say in 2.9.1</p>
</div><div style="white-space:normal"><blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(119,119,119);color:rgb(119,119,119)"><p dir="auto">An instance initialization method may not be declared in a value class or an interface (4.6).</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">and in 2.9.4</p>
</div><div style="white-space:normal"><blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(119,119,119);color:rgb(119,119,119)"><p dir="auto">A value class instance creation method may not be declared in an identity class, an abstract class, or an interface (4.6).</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">Then in 4.6 we reaffirm these restrictions on <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)"><init></code> and <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)"><vnew></code>, along with many similar pre-existing restrictions.  These are restrictions on <em>declaration</em> of special methods.</p>
<p dir="auto">Then in 4.9.1 we have similar static constraints on <em>uses</em> of special methods, by bytecodes.  Such constraints also appear on constants in the constant pool, in 4.4.8.</p>
<p dir="auto">Eventually in 5.3.5 we discover when and what we must throw if any of these conditions fail:</p>
</div><div style="white-space:normal"><blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(119,119,119);color:rgb(119,119,119)"><p dir="auto">If the purported representation is not a ClassFile structure (§4.1, §4.8), loading throws an instance of ClassFormatError.</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">IIRC somewhere there is a place in chapter 4 that tells us that all of the many requirements will be enforced.  I don’t remember where that promise is made.  (Remind me?)</p>
<p dir="auto">The phrases “instance initialization method ” and “value class instance creation method” are accompanied by  cross references to 2.9.1 and 2.9.4.  I’m starting to think that the cross references should <em>also</em> mention the special method names <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)"><init></code> and <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)"><vnew></code>.  That would be a new thing for the JVMS but makes more are more sense as we add more and more special method names.  Now we are at three such names; maybe it’s time to mention the names along with the cross references.  I think I should be able to grep the JVMS for <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)"><vnew></code> for mentions of this feature, not just the phrase “value class instance creation method” or the section number 2.9.4.  For example:</p>
</div><div style="white-space:normal"><blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(119,119,119);color:rgb(119,119,119)"><p dir="auto">Only the invokestatic instruction is allowed to invoke a value class instance creation method (2.9.4 `<vnew>`).</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">At some time we will want to change JVMS language that says things like “not <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)"><clinit></code>, <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)"><new></code>, or <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)"><vnew></code>” to “not a special method name”.  Is that time now yet?  Places that allow some but not all would have to say “not a special method name other than <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)"><clinit></code>” or something of that nature.  I think that would expose some irregularities in our treatment of “surprising” names, but that’s all to the good, even if embarrassing.</p>
<p dir="auto">You have this commentary:</p>
</div><div style="white-space:normal"><blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(119,119,119);color:rgb(119,119,119)"><p dir="auto">As an alternative naming scheme, we could re-use <init> but give the method a non-void return type.</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">You could also say something like:</p>
<blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(119,119,119);color:rgb(119,119,119)">
<p dir="auto">An alternative implementation technique could use regular static methods (presumably marked with a <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">Synthetic</code> attribute) of a standard name to implement constructors of value classes.  This would be convenient for some tools in that they could treat these factory methods like all other factory methods, without learning the new rules for <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)"><vnew></code> symbols, but would be inconvenient for other tools, including the JVM, which need to make a clear distinction between constructors and other methods.</p>
</blockquote>

</div></div></div>


</blockquote></div>