JDK-8252183 : [JEP 390] Add 'lint' warning for @ValueBased classes
  • Type: Enhancement
  • Component: tools
  • Sub-Component: javac
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-08-21
  • Updated: 2020-12-14
  • Resolved: 2020-12-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 16
16 masterFixed
Related Reports
Blocks :  
CSR :  
Duplicate :  
Relates :  
Relates :  
Sub Tasks
JDK-8254274 :  
Description
Implement a 'lint' warning in javac for a 'synchronized' statement whose operand is known to be @ValueBased.

This should apply to an operand expression that has any of:
- A class type, where the named class is declared @ValueBased
- An interface type, where the named interface is declared @ValueBased
- A type variable or intersection type with a @ValueBased bound

Comments
Changeset: 48d8650a Author: Dan Smith <dlsmith@openjdk.org> Date: 2020-12-08 23:04:01 +0000 URL: https://git.openjdk.java.net/jdk/commit/48d8650a
08-12-2020

I have attached the patch that has been successfully brought forward from past work a couple of years ago - This passes all tests on JDK16 tip. It needs much cleanup since it issues many more diagnostics than we want and also the semantics of what is legal with inline types has changed (and so what usage of VBCs need to be warned changes too)
06-10-2020

The patch from the past issues the following diagnostics: (Furnished below are the diagnostic keys and the actual messages) Several of these are (such as ==, !=, null mixing etc) are legal constructs now as their semantics have changed. A few other diagnostics are not required anymore since the scope has been limited and "class declarations need not depend on javac for guidance about meeting the requirements of value-based classes" Need to go through the list and eliminate all unneeded checks. (1) compiler.warn.value.based.class.must.be.final=\ value based class must be declared final (2) compiler.warn.value.based.class.may.not.extend=\ value based class may not explicitly extend another class (3) # 0: name (of method) compiler.warn.value.based.class.must.define.method=\ value based class must define an implementation of {0} - (3) was Issued for missing hashCode(), equals() and toString() - (4) compiler.warn.field.of.value.based.class.must.be.final=\ instance fields of value based classes must be declared final (5) compiler.warn.attempt.to.synchronize.on.instance.of.value.based.class=\ attempt to synchronize on an instance of a value based class (6) # 0: name (of method) compiler.warn.method.should.not.be.invoked.on.instance.of.value.based.class=\ the method {0} of java.lang.Object class cannot be invoked on a value based class instance (6) was issued when jlO's hashCode, equals, toString is invoked via super.hashCode() etc. (7) # 0: name (of operator) compiler.warn.value.based.class.instances.should.not.be.compared.with=\ value based class instances should not be compared with {0} (7) was issued when == and != operators had one or more operands that are VBCs. This is not illegal anymore (8) compiler.warn.value.based.class.with.accessible.constructor=\ value based class should not provide an accessible constructor (implicit or explicit) (9) compiler.warn.no.identity.for.value.based.class.instance=\ instances of a value based class do not have identity > (10) compiler.warn.null.mixed.with.value.based.class=\ suspicious mixing of ''null'' with an instance of a value based class (11) compiler.warn.nullable.casted.to.value.based.class=\ suspicious cast of a nullable instance to a value based class (12) compiler.err.bad.value.based.anno=\ Unexpected @ValueBased annotation
06-10-2020

Update: I've revised the description to indicate the limited scope: - The annotation will *only* be applied to JDK classes, and those class declarations need not depend on javac for guidance about meeting the requirements of value-based classes. (So, e.g., no "this class isn't final" warnings.) - Similarly, JDK class authors are responsible for ensuring the annotation is applied to implementing classes, rather than relying on javac to simulate annotation inheritance. - No analysis of factory methods needs to be performed. Methods like 'List.empty()' will not get compile-time warnings. (It's just too much complexity for little benefit.)
05-10-2020

The attached patch lintvalues.patch.v4 is the 4th iteration of patch that went through various rounds of reviews 2.5 years ago on behalf of JDK-8203465 - It surely would have gathered a fair bit of bit rot - but can be a starting point.
29-09-2020