On 1 Jun 2023, at 12:34, Brian Goetz wrote:
On 6/1/2023 2:32 PM, Dan Heidinga wrote:
On Thu, Jun 1, 2023 at 1:59 PM Brian Goetz <[email protected]>
wrote:
I think that there should be an explicit (and not synthetic)
method_info for the implicit constructor, with the obvious Code
attribute (`defaultvalue` / `areturn`.)
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.
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.
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....
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.
I’m assuming (a) the `aconst_default` 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 `new C()`) or else via
some reflective API point (`C.class.defaultValue()`). Maybe something
very simple like:
```
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();
}
```
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.
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.
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.
