Bug ID: JDK-8254047 [JEP 390] Revise "value-based class" & apply to wrappers

Versions (Unresolved/Resolved/Fixed)

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

Update ValueBased.html to reflect the JEP's constraints on inline class migration:

 - Is `final`,

  - Declares only `final` instance fields,

  - Extends `Object`, or a hierarchy of abstract classes that declare no instance
    fields and have no instance initialization logic,

  - Declares only `private` constructors, or has deprecated its constructors for
    removal,

  - Does not promise a unique instance will be created with each factory method
    invocation (or any other instance creation mechanism),

  - Does not rely upon or expose object identity through any of its methods,

  - Overrides `toString`, `equals`, and `hashCode`, and

  - Declares no `synchronized` methods, and discourages clients from performing
    synchronization.

Update the specs of the 8 primitive wrapper classes (Boolean, Character, Byte, Short, Integer, Long, Float, Double) to indicate that they are value-based classes.

No longer designate subclasses of ConstantDesc as value-based, because most of these classes declare their own fields.

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

Updated description to include changes to the primitive wrapper specs so that they are considered value-based. (The definition of "value-based" will need to carefully account for unique properties of these classes, like the cacheing guarantees of their 'valueOf' methods.)

13-10-2020

Changing the definition of Value-Based is a spec change and will need a CSR. Changing the behavior of existing classes by adding references to ValueBased.html is a spec change for each class. Though the warnings are applicable to JDK 16, the change in behavior cannot/should change for existing classes without the usual warning period. So if text is added to classes to be marked as @ValueBased, that text must make it clear that the class *will* change to value based in the future and is not value based currently.

09-10-2020

Blocks :	JDK-8249100 - JEP 390: Warnings for Value-Based Classes
CSR :	JDK-8254944 - [JEP 390] Revise "value-based class" & apply to wrappers
Relates :	JDK-8257845 - Integrate JEP 390

JDK-8254275 :	[valhalla/jep390] Revise "value-based class" & apply to wrappers - Resolved
JDK-8257776 :	[valhalla:jep390] Add disclaimer about future changes to value-based classes - Resolved