Clarification needed about primitive wrappers?
brian.goetz at oracle.com
Fri Jul 10 14:24:57 UTC 2020
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?
>> 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 :)
More information about the valhalla-spec-observers