<!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 1 Jun 2023, at 11:49, Dan Smith 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">The problem here is we have a language/VM model mismatch.</p>
</blockquote></div>
<div class="markdown" style="white-space: normal;">
<p dir="auto">It is also an opportunity.  The JVMS does not (and should not) exactly track the JLS.  The JLS “erases” Java code to classfiles, and those classfiles rely on the JVMS, not the JLS.  There are many JLS-level invariants and constructs which are (and should be) invisible to the JVMS.</p>
<p dir="auto">The rules for default-value processing are (and should be) different in the JLS and JVMS.</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">In the VM model: <vnew> is a factory method that can do whatever it wants, and be included or not included. All that matters for default values is ImplicitCreation.</p>
</blockquote></div>
<div class="markdown" style="white-space: normal;">
<p dir="auto">Yes, and <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">aconst_default</code> is yet another VM operation distinct from <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;"><vnew></code> (because the latter builds on top of the former).  But the JLS should not (I think) expose the distinction.  The translation strategy can use either primitive as appropriate to materialize defaults.</p>
<p dir="auto">My suggestion is to translate <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">new C()</code> as a real <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">invokestatic</code>, but consider using something else (reflective <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">condy</code> or <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">aconst_default</code> inside the nest) for other materializations of the default, if any.</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">In the language model: the implicit constructor allows both 'Foo.default' and 'new Foo()', both of which produce the same value.</p>
</blockquote></div>
<div class="markdown" style="white-space: normal;">
<p dir="auto">(I partially agree that the syntax <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.default</code> might possibly have outlived its usefulness.  Why not just <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">new C()</code>?  Maybe <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">C.default</code> is a switch constant expression…?)</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">Yes, it's possible to generate bytecode that doesn't conform to the language model, that's always the risk of designing a language/VM mismatch. But this feels to me like more of the same in the constructor space—e.g., we've already got VM-level abstract classes that can have <init> methods that won't run for value class instance creation, but will run for identity class instance creation.</p>
</blockquote></div>
<div class="markdown" style="white-space: normal;">
<p dir="auto">This is what happens with two specs, the JLS and JVMS.  The JVMS does not (and must not) undertake to enforce every JLS invariant.</p>

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

</html>