L-world nullability migration

Srikanth srikanth.adayapalam at oracle.com
Mon Mar 19 08:50:10 UTC 2018


Hi Karen,

I will require some clarifications in understanding the set of mails on 
this topic.
See below for questions/comments:

On Wednesday 14 March 2018 08:22 PM, Karen Kinnear 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.

While it may be possible to enumerate the set of value based classes in 
JDK that can evolve into value types, I am assuming that we also need to 
consider migration of types outside of JDK - in user land that may also 
evolve into value types from having existed as classic reference types 
earlier in third party libraries. And the VM may encounter these types 
in classes that are not recompiled afresh -
Is this correct ??

>
> 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.

I get why you would want to unburden the programmer from having to 
always flag __Flattenable fields and have the flattening decision be 
keyed off mere/very value-ness. John has also talked about at some point 
flipping the default on __Flattenable.

But I don't think this has anything to with javac being strict or not - 
right ? I think earlier discussions made it clear that in freshly 
compiled code that is compiled at value-aware source level, null should 
not be allowed to be assigned to value instances (whether flattenable or 
otherwise), that null cannot be cast into a value type or be compared 
with a value instance.

> 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.

OK,

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

If it is only JDK classes that are of interest javac can maintain a 
enumerated list of types - but I don't think that is the case - right ?

The way to do that for the general case would be via a modifier - 
__ByValue per se does not say anything about whether the so flagged 
class is a brand new value type or is one that is being evolved/migrated 
from an earlier value-based avatar. So perhaps we need a 
different/additional modifier such as __PureValue say.


>
> 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?

It is feasible that javac could have a lint mode to catch both identity 
and nullability issues and emit diagnostics - at a release that predates 
the eventual values fearures enablement.

For the chart, I will ignore the one below and share comments on the 
version you have shared later.

Thanks
Srikanth

>
>
> 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 
>> <mailto: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
>>
>



More information about the valhalla-dev mailing list