<div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 6, 2023 at 10:47 PM 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">
<p dir="auto">On 1 Jun 2023, at 12:34, Brian Goetz wrote:</p>
</div><blockquote style="margin:0px 0px 5px;padding-left:5px;border-left:2px solid rgb(119,119,119);color:rgb(119,119,119)"><div id="m_641506051233085166491B88780-877B-4825-95AE-44ED5EDDD65F">
<br>
<br>
<div>On 6/1/2023 2:32 PM, Dan Heidinga wrote:<br></div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr"><br></div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Jun 1, 2023 at 1:59 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@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">
<div><font size="4"><font face="monospace">I think that there should be an explicit (and not synthetic) method_info for the implicit constructor, with the obvious Code attribute (`defaultvalue` / `areturn`.) </font></font></div>
</blockquote>
<div><br></div>
<div>I'm slightly concerned about having a Code attribute for the implicit constructor as it allows agents (ClassFile load hook & redefinition) to modify the bytecodes to be inconsistent with the VM's behaviour given the VM won't actually call the implicit constructor.</div>
<div><br></div>
<div>Telling users it's "as if" the VM called the implicit ctor and then having the reflective behaviour be different after retransformation is slightly uncomfortable.</div>
</div>
</div>
</blockquote>
<br>
I'm fine if the expansion of the constructor body happens at runtime rather than compile time; my suggestion was mostly "this is super-easy in the static compiler, why make more work for the JVM." But, if you're signing up for that work, I won't stop you....<br>
<br>
<br></div></blockquote>
<div style="white-space:normal"><p dir="auto"><br>
I haven’t signed up the JVM for that work! It seems like busy-work to me. JVM code which implements some busy-work requirement costs money for no benefit, and its (inevitable) bug tail risks increased attack surfaces.</p></div></div></div></blockquote><div><br></div><div>Definitely curious about the busy-work here as my mental model for this is that it's a fairly cheap implementation akin to the code required to throw AbstractMethodError.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">I’m assuming (a) the <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">aconst_default</code> bytecode is not API (it’s private) and therefore that (b) any materialization of a default value will go through either the class’s API (real <code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">new C()</code>) or else via some reflective API point (<code style="margin:0px;padding:0px 0.4em;border-radius:3px;background-color:rgb(247,247,247)">C.class.defaultValue()</code>). Maybe something very simple like:</p>
<pre style="margin-left:15px;margin-right:15px;padding:5px;background-color:rgb(247,247,247);border-radius:5px;overflow-x:auto;max-width:90vw"><code style="margin:0px;border-radius:3px;background-color:rgb(247,247,247);padding:0px">C defaultValue() {
// if the next line throws an exception, it goes to the client
var a1 = Array.newInstance(asNonNullable(), 1);
// at this point we know C has a default value
return (C ) Array.get(a1, 0);
//OR?? return this.newInstance();
}
</code></pre>
<p dir="auto">Regarding the problem of agents, I’d say either we don’t care what a buggy agent does, or else we can might add an implementation restriction that refuses to allow a buggy agent to load an implicit constructor with a bad body.</p>
<p dir="auto">Agents can modify all sorts of JDK internals. (Also non-javac-spun classfiles explore all sorts of odd states.) We can’t play whack-a-mole trying to prevent all kinds of agent misbehavior. That would just end up creating an endless parade of costs and bugs.</p></div></div></div></blockquote><div><br></div><div>Agreed. I'm not concerned about buggy agents but about user expectations and avoiding an attractive nuisance. By having bytecodes in the implicit constructor, we encourage users to think they can modify its behaviour. Again, user expectation matters. Though these typically will be power users so there's more leeway for technical explanations.</div><div><br></div><div>Detailing the way the implicit language level constructor generates both the ImplciitCreation and the helper <vnew> method would be a great fit for the (non-existent) translation guide. I'm OK with spec'ing our way out by saying the <vnew> generated for the implicit constructor is only a helper but I don't know which spec we would put that info in.</div><div><br></div><div>--Dan</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">And I don’t want to add a verification rule; the costs of tweaking the verifier far outweigh the benefits. Let’s give some basic trust our classfile generators and agents.</p>
</div></div></div>
</blockquote></div></div>