JDK-8244227 : [lworld] Explore an implementation where the reference projection and value projection types are backed by a single class symbol
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: repo-valhalla
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2020-05-01
  • Updated: 2021-04-09
  • Resolved: 2021-04-09
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.
Other
repo-valhallaFixed
Related Reports
Relates :  
JDK-8237072 - [lworld] Add support for denoting and deriving the reference projection
Description
The proposed solution for JDK-8237072 uses two class symbols to
back/model the V.ref and V.val projection types. 

This was chosen because some of the state that (naturally) today belong in the class symbol abstraction needs to be distinct between the two projections. (name, flags, type ...) 

Also various parts of javac code compare tsyms and assume the types are same if they are same (on the non-parameterized type path) 

This ticket is to explore whether it would lead to a simpler implementation if we model them as one class and two projection types (a la one generic class and as many as needed parameterized types)

The upside of that approach is clear: We don't have to go to the trouble of maintaining the symbols in sync. It also aligns with the pedantic model of an inline class giving rise to two projection types. Having two classes is something of a distortion of that model and may have some impact in future that is unknowable now.