Bug ID: JDK-8203465 Add a lint mode for diagnosing violations of specification for value based classes

Type: Enhancement
Component: tools
Sub-Component: javac

Priority: P4
Status: Resolved
Resolution: Duplicate
OS: generic
CPU: generic

Submitted: 2018-05-21
Updated: 2020-09-29
Resolved: 2020-09-29

Since Java 8 we have had the notion of "Value Based Classes" as specified by  src/java.base/share/classes/java/lang/doc-files/ValueBased.html reproduced inline here:

// --------------------------------------------

Value-based Classes

Some classes, such as java.util.Optional and java.time.LocalDateTime, are value-based. Instances of a value-based class:
    - are final and immutable (though may contain references to mutable objects);
    - have implementations of equals, hashCode, and toString which are computed solely from the instance's state and not from its identity or the state of any other object or variable;
    - 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 (==);
    - do not have accessible constructors, but are instead instantiated through factory methods which make no committment as to the identity of returned instances;
    - are freely substitutable when equal, meaning that interchanging any two instances x and y that are equal according to equals() in any computation or method invocation should produce no visible change in behavior.

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.

// --------------------------------------------

It is now requested that Javac implement a lint mode that checks for violations of this specification and emit suitable warnings. This is to facilitate migration/evolution of such value based classes into full blown value types as and when such types get supported in the language.

In any event, it is useful to have a lint mode that checks for violations of the contract given that we have a specification for value based classes.

This feature would required value based classes to be tagged somehow, very likely with a @ValueBased annotation

The lint mode is envisaged to be an opt in mode.

Action has shifted to JDK-8252183. Closing this as duplicate
29-09-2020
The static checks via the lint mode and the dynamic checks in the VM are planned to be released together whenever value types support previews.
21-11-2018
Another check that the lint mode will perform is to make sure that a value based classes is not declared to extend a super class explicitly.
21-05-2018
(Summarizing some private mail exchanges) While the specification above is silent on assignment of nulls to, conversion of nulls to and comparison of nulls with a value based class, we should plan to emit warnings for these cases. The value based classes specification "is intentionally silent on nulls in that we knew nullability was a problem but we didn��t think we could realistically tell people that instances of a VB type (e.g., LocalDateTime) couldn��t be null, since that��s the default value the VM assigns when you allocate an array or create a field." However, a linter still should explicitly check for assigning a null literal to such a type, since that��s evidence that it is being used in a non-value-based way. Adding these checks for nulls will mean there will be less to shake out, as and when a VB type changes to a proper value type (if client code is cleaned up of all null related lint warnings and has no visible uses of null)
21-05-2018