SoV-3: constructor questions

[Dan Heidinga]

After re-reading the State of Valhalla part 3 again [1], I have a
couple of questions on constructor handling:

1) The rules for handling ACC_PERMITS_VALUE are different between
SoV-2 and SoV-3 in that the language imposes constraints the VM
doesn't check.  Is this deliberate?

SoV-2 says:
> The classes they can extend are restricted: Object or abstract classes with no fields, empty no-arg constructor bodies, no other constructors, no instance initializers, no synchronized methods, and whose superclasses all meet this same set of conditions. (Number is an example of such a class.)

while SoV-3 says:
> Perhaps surprisingly, the JVM does not perform the following checks for value-superclass candidates, although the source language compiler will typically do so:
>
> It should have declared an empty no-argument constructor. (Or if it didn’t, then the author has somehow consented to having all of the constructors being skipped by the unnamed factory methods of value subclasses.)

"Perhaps surprisingly" is right as I'm surprised =)  and not sure I
follow why the VM wouldn't enforce the restriction.  Is it to avoid
having to specify the attributes of that constructor?

Which leads me to the next concern: how javac will compile the "empty
no-arg constructor bodies" required by SoV-2?  Or is the answer we
don't care because the VM won't check anyway?

2) What is the rationale behind the return type restrictions on <new> methods?

> A <new> method must return the type of its declaring class, or a supertype.
....
> While <new> methods must always be static and must return a type consistent with their class, they can (unlike <init> methods) be declared in any class file, as far as the JVM is concerned.

If I'm reading this correctly, to enforce the first quote we'll need a
verifier check to ensure that the declared return type of the <new>
method is consistent with the current class or a supertype.  But
Object is a common supertype, as is ValueObject, so I'm not sure what
we're gaining with this restriction as any type is a valid candidate
for return from a <new> method as anything can be a subclass of
Object.

We get a better restriction from the `aconst_init` and `withfield`
bytecodes which "can only be executed within the nest of the class
that declares the value class being initialized or modified".  Do we
actually need the restriction on the <new> method or should it be
considered non-normative (aka a best practice)?

--Dan





[1] https://openjdk.java.net/projects/valhalla/design-notes/state-of-valhalla/03-vm-model