[External] : Re: Proposal: Static/final constructors for bucket-3 primitive classes.

[forax at univ-mlv.fr]

----- Original Message -----
> From: "John Rose" <john.r.rose at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>, "clement
> cherlin" <clement.cherlin at gmail.com>
> Sent: Thursday, December 9, 2021 9:45:11 AM
> Subject: Re: [External] : Re: Proposal: Static/final constructors for bucket-3 primitive classes.

> On Dec 8, 2021, at 11:12 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> I fully agree, i think it's better to do the opposite
> 
> I snapped a few neurons trying to read that the first time.

hum, there is a missing 'but' after the comma ...

> 
>> and force the fact that all primitive value classes (Bucket 3) must have a
>> default constructor and that constructor have a fixed bytecode instructions.
> 
> Heavy on ceremony even for Java especially if you can’t do anything valuable in
> the constructor body.
>> 
>> If a user does not provide a constructor without parameter, the compiler will
>> provide one and the verifier will check that this constructor exist.
> 
> That’s JVM ceremony, to what end?

Users are used to constructors, but bucket 3 inherently has an escape hatch because you can create an instance bypassing the constructors.

Bypassing the constructors is bad, we know that because this is what the serialization does, so instead of letting people to figure out out of blue that they should use B2 instead of B3 for such classes, i think it's better to maintain the illusion that there is a default constructor with no parameter for all B3.

It makes the semantics of B3 very clear, by making a public default constructor mandatory.

The JVM ceremony is not strictly necessary, i propose it so if people uses another bytecode generator than javac, things are still nicely aligned between the JLS and the JVMS view of the world, but it's less important.

> 
> Maybe we should disallow no-arg constructors altogether and leave room for a
> possible future feature along the lines of the special init phase. That future
> feature would run ad hoc byte codes at class preparation time to build thyroid
> default value and would throw an error if it touched the class. Kind of like
> superclass init actions; after those and before the proper clinit call.
> 
> It’s possible but not a priority, because of the various expenses I sketched. So
> we could leave space for it to put in later if the costs were justified after
> all.

We may do something like that in a possible future, but i think it's more important to make the semantics of B3 visible front and center.

Rémi