Having the deeper investigation into how this affects the specs will
help a lot.
A very quick perusal of the VM spec raises some questions about how
we'll handle the existing primitive special cases without continually
grouping built-in primitives separately from {primitive objects,
references}. A clean model for dealing with the 3 concepts will be
essential.
The Verification Type System (JVMS 4.10.12) will also need some
attention as the terms "primitive object type" and "primitive
reference type" will both need to live under the "reference"
hierarchy. If in the "Java language, the existing primitive values
will become primitive objects" we'll need some special casing between
the two specs to avoid backedges from "primitive object type" to the
{int, float, twoWord} cases in the type system.
>From a user perspective, will the new terms encourage the right mental
model for when value types get flattened (or not)? As an EG, early on
we spent a lot of time discussing "flattened" vs "flattenable" and
trying to guide users to the view that this is a VM-level decision and
not a guarantee. Does leaning on the "pass by value" inituition undo
that previous work?
--Dan
On Wed, Oct 7, 2020 at 9:37 AM Brian Goetz <brian.go...@oracle.com> wrote:
>
> Yes, though a more thorough investigation is in order if we think this is a
> good direction.
>
> In the first round, the main problem was the use of "value" as both noun and
> adjective, giving us weird locutions like "the value set of a value type", or
> "if the value is a value". This was clearly going to be a problem.
>
> In this round, the adjustments are more straightforward. For example, we
> will likely have to adjust phrases like "primitive values" to something like
> "primitive objects", and "primitive types" to either "primitive value types"
> or "built-in primitive value types", depending on context. But most of these
> involve being _more precise_ about the terminology.
>
>
>
>
>
>
> On 10/7/2020 9:14 AM, Dan Heidinga wrote:
>
> One of the things that moved us away from the use of the term "value"
> was the violence it would do to the Java and JVM specs. Has a similar
> analysis been done on how using primitive objects will affect the
> existing specs?
>
> --Dan
>
> On Wed, Oct 7, 2020 at 6:19 AM Remi Forax <fo...@univ-mlv.fr> wrote:
>
> I'm fine with that change.
>
> For me, it's more where you put the emphasis
> - how it behaves on stack, it behavse like a primitive type ,the "pass by
> value" Dan is talking about
> - how it behaves on heap, it behaves by inlining itdelf in its container.
>
> So they are a primitive inlining class :)
>
> Rémi
>
> ________________________________
>
> De: "Brian Goetz" <brian.go...@oracle.com>
> À: "daniel smith" <daniel.sm...@oracle.com>, "valhalla-spec-experts"
> <valhalla-spec-experts@openjdk.java.net>
> Envoyé: Lundi 5 Octobre 2020 21:22:15
> Objet: Re: Terminology update: primitive objects
>
> There's always been a duality between whether inline classes are "faster
> objects" or "user-programmable primitives." Until now, we're been erring on
> the "faster objects" side of the line, but after some thought, we think that
> flipping the perspective will better frame what these new features are for.
>
> The obvious stumble you have to get over before this idea is appealing is
> "but these are not primitives." So we have to be explicit about that. But,
> once you buy that, I think these terms work much better.
>
>
>
> On 10/5/2020 3:18 PM, Dan Smith wrote:
>
> We've been struggling with some uncomfortable rough edges of the "inline
> class"/"inline type" terminology for awhile. After multiple rounds of
> bikeshedding, here's an alternative that the Oracle team feels pretty good
> about:
>
> - A *primitive object* is a new kind of object that lacks identity. It has
> special behavior with respect to equality, synchronization, and related
> operations. *Identity object* describes all other objects (including arrays).
> (The new objects are "primitive" in the sense that they are lighter-weight
> and represent simple, immutable values.)
>
> - A *primitive class* (formerly *inline class*) is a special class whose
> instances are primitive objects. Primitive classes are always concrete and
> final, and their declarations are subject to various restrictions. A class
> that is not primitive is either an *identity class* or an *abstract class*
> (or Object, if we don't end up making it abstract).
>
> - A *primitive value type* (formerly *inline type*) is a type whose values
> are primitive objects—the objects themselves, not *references* to the
> objects. Each primitive class has a primitive value type, typically denoted
> by the class name.
>
> - A *primitive reference type* is a type whose values are references to
> primitive objects, or null. Each primitive class has a primitive reference
> type, typically denoted as ClassName.ref.
>
> - The general term *primitive type* refers to either a primitive value type
> or a primitive reference type. The general term *reference type* continues to
> mean a type whose values are reference to objects (of unspecified kind), or
> null.
>
> - In the Java language, the existing primitive values will become primitive
> objects, with java.lang.Integer, etc., acting as their primitive classes.
> When needed, *built-in primitive value type*, etc., can be used to refer to
> their types. In the JVM, something like *primitive object type* might be
> appropriate to distinguish between primitive objects and the built-in
> numerics.
>
> The type terminology leans on intuitions about "pass by value" and "pass by
> reference". Some languages pass *variables* by value or reference, but in
> Java the, er, primitive, is passing *objects* by value or by reference.
> Similar properties apply in both contexts.
>
> ---
>
> This is a brief sketch, just enough to define the terms. Future documents,
> including project overviews, JEPs, and specs, will illustrate use of the
> terms in the broader context of the language and VM.
>
>
>
>
