L-world nullability migration

[Karen Kinnear]

Summary - proposing that we add a clue (annotation?) for javac that a value-based class
is migrating to become a value type, and allow javac to be strict with new value types
and have a choice on handling migrating types. The JVM will continue to be lenient
to allow migration.

Attachment did not come through - so I put this all in one document - updated proposal:

http://cr.openjdk.java.net/~acorn/L-World%20Nullability%20%26%20Migration.pdf

thanks,
Karen

> On Mar 14, 2018, at 10:52 AM, Karen Kinnear <karen.kinnear at oracle.com> wrote:
> 
> 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
>> 
>