Implicit constructor of the super class of a null restricted value class

Dan Smith daniel.smith at oracle.com
Mon Oct 23 18:15:41 UTC 2023


On Oct 23, 2023, at 9:33 AM, forax at univ-mlv.fr wrote:

- Existing constructor is protected. Replace it with a (public) implicit
constructor. No meaningful change in accessibility.

It depends if the class is abstract or not.
Do we allow a value class to extends a non-abstract class, like Timestamp inherits from Date ?

No, superclasses of value classes must be abstract classes (or Object).

This is because concrete classes are always either 'identity' or 'value' (or Object), and concrete 'value' classes must be final.

We can revisit some of these assumptions, but I don't think there's a strong motivation for the added complexity. (In effect, we'd be talking about taking the weirdness of Object, a non-identity class with (direct) identity instances, and promoting it to a full-scale language feature.)

- Existing constructor is package-access. Declaring an implicit constructor will
allow more subclasses to extend it. Only other mechanism for controlling who
can extend the class is 'sealed'; that may be a reasonable workaround, given
that all subclasses are in the same package.

- Existing constructor is private. Same as package-access, except 'sealed' is
even easier, since the 'permits' clause can be inferred.

So, yes, there's a meaningful change in the package-access/private case.

You have forgotten that "sealed" requires that the permittted subclasses have a stable name, for example, you can not use sealed if one of the permitted subclass is local to a method.
Sealed is not a replacement for the constructor accessibility.

I mean, sure. Now we're in extreme corner case territory. But yes, you can construct examples in which 'sealed' is a somewhat inconvenient workaround.

The trade-off for supporting limited constructor access is that the VM would
have to work harder to validate it: as described currently, ImplicitCreation is
a boolean flag. If access could be restricted, the access level would have to
appear in the ImplicitCreation attribute and be enforced at class loading.

yes,
the attribute ImplicitCreation should to be extended to

ImplicitCreation_attribute {
   u2 attribute_name_index;
   u4 attribute_length;
   u2 access_flags;      // <-- add an access flag here
}

"Is capable of being extended to": sure, absolutely, we could do that.

"Should be extended to": as I said, I don't think these use cases are worth it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20231023/3a2c2bcf/attachment-0001.htm>


More information about the valhalla-spec-observers mailing list