a new job for <init>: "static init factories"

John Rose john.r.rose at oracle.com
Fri Apr 26 01:51:36 UTC 2019

On Apr 24, 2019, at 11:00 AM, John Rose <john.r.rose at oracle.com> wrote:
> To do this, we will need to make some changes to the JVM
> specification (and implementations).  Here are the changes
> I propose:
> * Relax constraints on CONSTANT_Methodref and CONSTANT_NameAndType
>  allowing free use of <init> as if it were a regular method name.
> * Retain all restrictions on use of <init> via invokespecial.
> * Allow an invokestatic to mention <init> (but no other bytecodes).
> * Retain all restrictions on definition of <init> methods *in regular non-inline classfiles*
> * Allow an inline classfile to define a <init> method, only with ACC_STATIC
> * Require that the type returned by such an <init> method is the containing class.
>  (Extra rider:  If the class is non-denotable, aka. hidden, returned class must be Object.)

Something subtle here:  Wherever we relax a restriction that affects
a use of invokespecial, we usually have to impose it somewhere else.
In particular, when the verifier processes a call to <init>, it should
(as a new responsibility) ensure that the called descriptor has a
void return.  An analogous check should look at CONSTANT_MH
constants of kind newInvokeSpecial, to make sure the signature
has a void return.

This is the intention of "retain all restrictions" in the second point,
which otherwise contradicts "relax constraints" in the first point.

More information about the valhalla-spec-observers mailing list