On 1 Jun 2023, at 11:49, Dan Smith wrote:
The problem here is we have a language/VM model mismatch.
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.
The rules for default-value processing are (and should be) different in the JLS and JVMS.
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.
Yes, and `aconst_default` is yet another VM operation distinct from `<vnew>` (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.
My suggestion is to translate `new C()` as a real `invokestatic`, but consider using something else (reflective `condy` or `aconst_default` inside the nest) for other materializations of the default, if any.
In the language model: the implicit constructor allows both 'Foo.default' and 'new Foo()', both of which produce the same value.
(I partially agree that the syntax `C.default` might possibly have outlived its usefulness. Why not just `new C()`? Maybe `C.default` is a switch constant expression…?)
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.
This is what happens with two specs, the JLS and JVMS. The JVMS does not (and must not) undertake to enforce every JLS invariant.
