I'm made some revisions to JEP 402 to better track with the revised JEP 401—in
particular backing off of "everything is an object".
There were some short-lived changes where I more aggressively pursued the idea
that the class was named 'int', but I've backed off of that, too. Now taking
the
#3 is more like:
primitive value vs. bare object
Or
primitive value vs. [something else] object
Where object is split not only into value object and identity objects, but bare
(value) objects are another split. You get bare vs heap just as you get value
vs identity as cleavage planes in the
EG meeting touched on a few different renaming ideas to consider. Wanted to put
those all down in one place.
Personally, I don't have strong feelings about any of these. I think the status
quo is reasonable, and these changes would probably be fine, too (modulo coming
up with the right word in
> From: "Brian Goetz"
> To: "Remi Forax"
> Cc: "valhalla-spec-experts"
> Sent: Wednesday, January 12, 2022 2:30:00 PM
> Subject: Re: [External] : Re: VM model and aconst_init
> The operand of C_Class is a weird beast. It can be an internal name
> (com/foo/Bar), but it can also be a
Can't attend today, but
On Wed, Jan 12, 2022 at 8:08 AM Dan Smith wrote:
"We have to talk about 'primitive'": terminology discussion regarding the
> word "primitive"
>
I'm planning to continue this conversation on-thread, so no worries for now.
--
Kevin Bourrillion | Java Librarian |
EG Zoom meeting today at 5pm UTC (9am PDT, 12pm EDT).
We've had a flurry of activity in the last month. The list is below; probably
best for those involved to decide whether they feel like the topic is settled,
or deserves further discussion.
"JEP update: Primitive Classes": revisions to JEP
The operand of C_Class is a weird beast. It can be an internal name
(com/foo/Bar), but it can also be a *descriptor* for an array type.
Valhalla extends it to allow Q descriptors as well (but not L
descriptors -- there should be one way to say C_Class[String].)
On 1/12/2022 8:14 AM,
> From: "Brian Goetz"
> To: "Remi Forax" , "valhalla-spec-experts"
>
> Sent: Wednesday, January 12, 2022 1:45:34 PM
> Subject: Re: VM model and aconst_init
> Both value and primitive classes use the aconst_init / withfield
> initialization
> protocol. The former is an L-type (QOptional is
- Original Message -
> From: "Brian Goetz"
> To: "Remi Forax" , "valhalla-spec-experts"
>
> Sent: Wednesday, January 12, 2022 1:27:07 PM
> Subject: Re: L-type, Q-type and class mirrors
>> Let's take a detour, and try to answer to the question, how do we do
>> reflection
>> on method
Both value and primitive classes use the aconst_init / withfield
initialization protocol. The former is an L-type (QOptional is
illegal); the latter uses Q types for initialization.
Value classes
-> are L types
-> which are references
-> references can be null
-> VM manages where the
I've some troubles to wrap my head around those two sentences
"""
aconst_init is the analogue of new for value objects; it leaves a reference to
the initial value for a value class on the stack. This initial value is
guaranteed to not be equal to null. The sole operand of this bytecode is a
Let's take a detour, and try to answer to the question, how do we do reflection
on method with Q-types ?
Given that reflection is using the class java.lang.Class, it means that we need
a class that represents a L-type and a class that represent a Q-type.
Correct. In addition to all sorts
Hi all,
i want to propose a way to reconcile builtin primitive types and primitive
classes in the B1/B2/B3 world.
Let's take a detour, and try to answer to the question, how do we do reflection
on method with Q-types ?
Given that reflection is using the class java.lang.Class, it means that we
13 matches
Mail list logo
