Clarification needed about primitive wrappers?

[Brian Goetz]

The reality is we are evolving our perspective as we gain experience with the model.  Once we prove out that we have something that actually works, There will be a round of updating the terminology.  

Sent from my iPad

> On Jul 10, 2020, at 8:54 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> From valhalla-spec-observers,
> 
> ----- Mail original -----
>> De: "Gernot Neppert" <mcnepp02 at googlemail.com>
>> À: "Valhalla Expert Group Observers" <valhalla-spec-observers at openjdk.java.net>
>> Envoyé: Vendredi 10 Juillet 2020 12:06:32
>> Objet: Clarification needed about primitive wrappers?
> 
>> Hello,
>> 
>> it seems some clarification is needed about the fate of the primitive
>> wrappers in "Valhalla-world".
>> In this and the related Mailing Lists, you can find the following two
>> proposals, with subtle differences:
>> 
>> 1. the primitive wrappers (java.lang.Integer etc) are designated to become
>> inline classes. This idea has been most recently cited in the posting
>> "Identity warnings for inline class candidates".
>> 
>> 2. the primitive wrappers should become the reference-projections of
>> corresponding inline classes. This has sometimes been augmented with the
>> idea that the denominations for the primitive types (such as "int") will
>> then become aliases for those new inline types.
>> 
>> So, what's it going to be?
> 
> The idea is to retrofit primitive types to be inline types, at the Java language level, not at the VM level.
> Once you have to done, given that a wrapper type is a way to transform a primitive type to an object,
> a wrapper type is the reference projection of the corresponding primitive type (which is now an inline type).
> 
> [...]
> 
>> 
>> But then, if we are going with proposal 2, what would be so special about
>> the reference-projections of the primitive types? Shouldn't all reference
>> projects be treated equally?
> 
> nothing special, it's more than the semantics of Integer now and the semantics of Integer being the reference projection of int are slightly different.
> 
>> Wouldn't it mean that synchronizing on an IdentityObject obtained via
>> reference-projection should always warrant a warning?
> 
> the reference projection is a projection not a boxing, so at runtime, the reference projection of an inline type is still an inline type, so a reference projection can not be an instance of IdentityObject.
> 
>> 
>> It may well be that all this is perfectly clear to you experts, however, it
>> might still be advantageous to use consistent wording everywhere!
> 
> I'm not sure it's perfectly clear even to us :)
> 
> Rémi
>