State of javac support for lworld-values.

Srikanth srikanth.adayapalam at
Mon Mar 26 07:48:06 UTC 2018

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

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:

(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)


More information about the valhalla-dev mailing list