State of javac support for lworld-values.

[Remi Forax]

----- Mail original -----
> De: "Srikanth" <srikanth.adayapalam at oracle.com>
> À: "Karen Kinnear" <karen.kinnear at oracle.com>, "John Rose" <john.r.rose at oracle.com>
> Cc: "valhalla-dev" <valhalla-dev at openjdk.java.net>
> Envoyé: Lundi 26 Mars 2018 11:21:17
> Objet: Re: State of javac support for lworld-values.

> On Thursday 15 March 2018 11:53 PM, Karen Kinnear wrote:
>> Srikanth,
>>
>> I sent a email yesterday, and just sent out a .pdf summarizing a new
>> proposal:
>> 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.
>>
>> http://cr.openjdk.java.net/~acorn/L-World%20Nullability%20%26%20Migration.pdf
>> <http://cr.openjdk.java.net/%7Eacorn/L-World%20Nullability%20%26%20Migration.pdf>
>>
>> If it makes sense to you and the langtools team -
>>
>> This would keep the strictness you have implemented for new value types.
>>
>> We would like to ask for a way to identify migrating value-based
>> classes to value types,
>> both so that we can write tests of JVM functionality, and of course so
>> that we can
>> experiment with migration and separate compilation.
>>
>> If you could find a way for us to identify in source that we have a
>> value-based class
>> migrating to a value type, and to limit the strictness for new value
>> types for now - that would
>> enable us to use javac to write tests for the JVM.
>>
>> It would also allow us all to start experiments with migration and
>> separation compilation,
>> which would be helpful for the JVM, as well as informative for the
>> langtools strictness
>> decisions.
> 
> Hi Karen,
> 
> I think I am hearing 4 goals for this proposal:
> 
>     1. A lenient mode in javac that does not issue errors for null
> related violations of value'ness - would enable you to use javac to
> write tests for the JVM.
> 
>     2. "It would also allow us all to start experiments with migration
> and separation compilation,which would be helpful for the JVM"
> 
>     3. Such a mode could be informative for the langtools strictness
> decisions.
> 
>     4. As a follow up of 3, it may become possible to provide the the
> eventual end programmers a gradual path to fixing value'ness violations
> instead of issuing hard errors.
> 
> 
> Are 1 & 2 already supported by invoking valhalla tip javac with -source
> 10 option of javac ?
> When invoked with -source 10, as long as the source code does not
> contain the tokens __ByValue,
> __Flattenable and __MakeDefault, the code should compile and any classes
> tagged __ByValue elsewhere would be treated as value based classes and
> would be compiled with no new/additional strictness.
> 
> $ cat X.java
> final __ByValue public class X {
>     final int x = 10;
> }
> 
> $ cat Y.java
> 
> public class Y {
> 
>     void doit(X x, X y) {
>         x = null;
>         x = (X) null;
>         if (x != null) {}
>         if (x != y) {}
>         if (null instanceof X) {}
>     }
> }
> 
> $javac X.java
> 
> // Now seperately compile Y.java *without* explicit -source 10:
> 
> $ javac -g Y.java
> Y.java:4: error: incompatible types: <null> cannot be converted to X
>         x = null;
>             ^
> Y.java:5: error: incompatible types: <null> cannot be converted to X
>         x = (X) null;
>                 ^
> Y.java:6: error: incomparable types: X and <null>
>         if (x != null) {}
>               ^
> Y.java:7: error: value types do not support !=
>         if (x != y) {}
>               ^
> Y.java:8: error: incompatible types: <null> cannot be converted to X
>         if (null instanceof X) {}
>             ^
> 5 errors
> 
> // Now seperately compile Y.java *with* explicit -source 10:
> 
> $ javac -g -source 10 Y.java
> warning: [options] bootstrap class path not set in conjunction with
> -source 10
> 1 warning
> 
> When invoked with -source 10 option, javac does not know anything about
> value types.
> Any class file that is referenced in that compilation that has the
> ACC_VALUE bit set or
> has a field with ACC_FLATTENABLE bit set will be treated as normal
> classes/fields - these
> flags bits will be silently ignored.
> 
> Is this not enough for goals 1 & 2 above ?
> 
> As for (4), I am not sure it is a great idea ! When eventually this
> functionality gets delivered and used by programmers, deferring errors
> to runtime - those that could be caught at compile time itself sounds
> very un-Java like to me.
> 
> I agree because of the way VM handles null assignments now - only
> flattenable fields and array cells may not be null - javac is
> necessarily more picky. But that serves its purpose in minimizing the
> surface where a null pollution may originate.
> 
> I will discuss this with the Javac team of course, but if there are
> convincing arguments already, I would like to hear.
> 
> If indeed (4) is of dubious value, it also drags (3) into question.
> 
> Please confirm if (1) and (2) are sufficiently addressed by javac
> -source 10 invocation.
> 
> Thanks!
> Srikanth

I agree with Srikanth, if we want to test the compatibility, the best is to compile the same way the code will be compiled in real life.

Does the sample below emits the same error ?
  if (y != x) {}

(4) in my opinion, should be solved by introducting in 11 of a serie of new warnings for the class that are marked as value based class.  
    All the errors on value types should be warnings on the value based class.

Rémi