implicit constructor translation?

[John Rose]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-experts/attachments/20230606/86034d5f/attachment-0001.htm>