State of javac support for lworld-values.

[Karen Kinnear]

Srikanth,

I really like your proposal of a lint mode for value-based classes for JDK 11.

Given we are exploring changing value-based classes behavior with nullability - I wonder if it is 
also worth adding an option to also detect if a value-based class is ever set to null (as you point
out through any assignment mechanism).

I know Mr Simms has been working on a similar set of checks for value-based classes for runtime for JDK 11.

Catching these early could definitely reduce the migration pain.

thanks,
Karen


> On Mar 26, 2018, at 3:48 AM, Srikanth <srikanth.adayapalam at oracle.com> wrote:
> 
> 
> 
> On Thursday 15 March 2018 11:53 PM, Karen Kinnear wrote:
>> 
>>>>  I would like to have a follow-up discussion about nullability of value types based on ACC_FLATTENABLE, 
>>>> and how to handle migration.
>>>> 
>>>> The key points below that I want us to revisit are:
>>>>>    - Value instances may not be compared with == or !=. == and != cannot have any value operand(s)
>>> 
>>> This is a conservative choice.  We could assign x.equals(y) as the meaning
>>> of x==y for x, y values.  That's a language team choice, and I don't see
>>> a decision on that coming soon.  I recommend filing a tracking issue.
>> Conservative for new value types.
> 
> Even for value based classes, instance comparison guidelines are clearly spelled out in
> https://docs.oracle.com/javase/8/docs/api/java/lang/doc-files/ValueBased.html <https://docs.oracle.com/javase/8/docs/api/java/lang/doc-files/ValueBased.html>:
> 
> Instances of a value-based class:
> 
> make no use of identity-sensitive operations such as reference equality (==) between instances, identity hash code of instances, or synchronization on an instances's intrinsic lock;
> are considered equal solely based on equals(), not based on reference equality (==);
> A program may produce unpredictable results if it attempts to distinguish two references to equal values of a value-based class, whether directly via reference equality or indirectly via an appeal to synchronization, identity hashing, serialization, or any other identity-sensitive mechanism. Use of such identity-sensitive operations on instances of value-based classes may have unpredictable effects and should be avoided.
> 
> I think John's "We could assign x.equals(y) as the meaning of x==y for x, y values.  That's a language team choice" allusion is       to "logical candidates" in the original document: http://cr.openjdk.java.net/~jrose/values/values-0.html <http://cr.openjdk.java.net/~jrose/values/values-0.html>
> (I realize that these guidelines are just that - they are not enforced and we are likely to encounter code that violates them. So the proposal to have a lint mode in jdk11 has merits)
> Srikanth