[lworld] RFR: 8244231: [lworld] Add support for ref-default and val-default inline classes.

Maurizio Cimadamore mcimadamore at openjdk.java.net
Thu Jul 22 10:00:00 UTC 2021

On Thu, 22 Jul 2021 08:11:17 GMT, Srikanth Adayapalam <sadayapalam at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4674:
>>> 4672:                     // reflect this.
>>> 4673:                     if (sym.isPrimitiveClass()) {
>>> 4674:                         if (sym.isReferenceFavoringPrimitiveClass()) {
>> Shouldn't we simplify this to try and use `asValueType` - probably this suggests there should be an `asReferenceType` too?
> ATM, we have com.sun.tools.javac.code.Type#referenceProjection()
> Again, I will use JDK-8268734 to rationalize the various internal APIs we have - while doing so, also looking at choice of terminology adopted by java.lang.Class  
> But I didn't understand the comment about the simplification you are suggesting - can you clarify ?

I mean - this code does a bunch of checks - and then creates a new class type with the opposite flavor/polarity. Isn't that what methods like `Type::asValueType` are supposed to do? E.g. if I have a reference-favoring primitive and I see `.val` can't I just get the type I want by calling `asValueType()` on it? If so, should we also have the dual?


PR: https://git.openjdk.java.net/valhalla/pull/482

More information about the valhalla-dev mailing list