State of javac support for lworld-values.

[John Rose]

On Mar 26, 2018, at 3:42 AM, Srikanth <srikanth.adayapalam at oracle.com> wrote:
> 
> On Monday 26 March 2018 04:00 PM, Srikanth wrote:
>> 
>> Does a lenient mode at the eventual release for ease of migration purposes amounts to foregoing the opportunity to slap on the wrists but the lead the application programmer down the path to blowing their entire foot (with a runtime error) ?
>> 
>> (Has the VM considered not NPEing for a null reference assignment to a flattenable field/value array cell, instead coalescing into the default value ? Does that make sense ? Afterall, anewarray comes up with default values)

I don't think the VM should ever allow a type T to be defined as a value type
and then allow a heap variable of exact type T to be nulled.  To allow that
would be to constrain all future implementations of value types, to ease
a few transient use cases.  Or, if not, it would constraint all future
implementations to recognize three (not two) kinds of classes:  Objects,
values, and object-like-values.  That's not a type system I want to see
in the JVM or the language.

(…Where heap variable := static field | instance field | array element, and
where exact type T means not a type such as Object or an interface
even if that is a valid super of some value type T.  Non-heap variables
have different design trade-offs, because their types are tracked
differently from heap variables, in the JVM.)

> If the VM were to be "forgiving" of null stores into value array cells or flattenable value field per above or any other scheme, then a lenient mode in javac would make immediate sense I think.

I'm pretty sure the VM won't forgive such things, at least not in
the long run.

As far as javac is concerned, until a type has made the leap into the
value-type world, it is a reference type, and can pull all the crazy tricks
that are permitted to references, even when they are in poor taste.

Adding in new hard restrictions on a half-way point seems (IMO) to
create a new entity in the Java type system, neither value nor
reference, but something in between.  I think we'd regret that.
Soft restrictions will let us avoid such a hard commitment.

The appropriate escape hatch is annotations, which are not allowed
to change semantics (generally speaking) but are allowed to gate
lint-like behavior.  Karen's idea to mark VBC's is a good one, but it
must be interpreted with one eye on existing reference semantics,
which means that warnings (not errors) are the appropriate severity,
akin to the raw-type and unchecked warnings on today's generics.

— John