L-world nullability migration

[Karen Kinnear]

I have been working through some of the migration issues with value field nullability
and wanted to bounce some ideas off of folks.

I think we are in agreement that the ideal world would make all value types flattenable -
whether in fields or in arrays. 

I have been trying to walk through the details of the migration steps which we are all struggling with,
with a possible approach of javac having a different permissiveness than the JVM.

So - I think this is a tightly bounded problem. I think today this is limited to a very small list
of value-based-classes. And perhaps in future there might be a handful of other classes that
qualify for migrating from identity objects to value based objects.

I was wondering if it were worth exploring distinguishing new value types from migrated objects at the language level. So for new value types - they would always be flattenable and javac should be strict.
There are no existing subclasses or clients for these objects, no existing APIs, no migration problem.
So always flattenable, no need to use a modifier.

Perhaps there is a way to give javac the information that a value-based-class is migrating to
become a value type.

Value-based classes are supposed to have no identity today, so we are less concerned about
catching identity issues. That said, we are talking about offering a flag to allow catching identity
issues during JDK11. We are also talking about having javac catch these and runtime throw exceptions.

Nullability is harder - because value-based classes are nullable today. That said, I think it might
be helpful to offer a flag to catch nullability issues which takes a specific classname for runtime.
Nullability might also require API changes.

So one question is - what is javac’s role here? Warnings? 

I think we have agreed that the JVM needs to handle the new classes and the migration, and that we currently have ACC_FLATTENABLE in the classfile to tell the JVM what behavior is expected by the container itself.

In practice - this is my model of migration.






> On Mar 13, 2018, at 8:55 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
> On Mar 13, 2018, at 5:12 PM, Srikanth <srikanth.adayapalam at oracle.com <mailto:srikanth.adayapalam at oracle.com>> wrote:
>> 
>> For value arrays, I don't think there is anything that expressly needs to be handled by javac. I will double check.
> 
> (that seems true to me too)
> 
>> For nullability, my understanding is that expectations are different for javac and the VM. That javac should regardless of the flattenable/array element status, forbid injection of nulls.
> 
> Yep.  The JVM is currently permissive about nulls, so that it can
> easily run down-rev classfiles without surprises.
> 
> But that could change.  In any case, javac should be non-permissive
> when it is compiling valhalla code.
> 
> — John
>