- Mail original -
> De: "Maurizio Cimadamore"
> À: "John Rose"
> Cc: "valhalla-spec-experts"
> Envoyé: Dimanche 3 Mars 2019 22:38:48
> Objet: Re: lazy statics design notes
> On 02/03/2019 19:37, John Rose wrote:
>> So, I want to defend my proposal a little more, not only by saying we'll
Hi Brian,
given that a value type is constructed by a factory method (the constructor is
desugared to a static method), why not making the serialization aware of that
factory method.
Rémi
- Mail original -
> De: "Brian Goetz"
> À: "valhalla-spec-experts"
> Envoyé: Lundi 11 Mars 2019 2
Hi Brian,
with an hat of JVM language implementor,
the attribute ForwardingBridge is important because it allows to simulate
things that are not co/contravariant for the VM but are from the language point
of view, like between an int and a Long.
I don't see the point of having two attributes, gi
> De: "Kevin Bourrillion"
> À: "Brian Goetz"
> Cc: "valhalla-spec-experts"
> Envoyé: Lundi 8 Avril 2019 20:25:24
> Objet: Re: generic specialization design discussion
> I'd suggest the name should in some way allude to the inline/compact/flat
> memory
> layout, because that is the distinguishi
in that case, direct class ?
Rémi
> De: "Brian Goetz"
> À: "Kevin Bourrillion"
> Cc: "valhalla-spec-experts"
> Envoyé: Lundi 8 Avril 2019 22:45:46
> Objet: Re: generic specialization design discussion
> And the opposite of “inline” is “indirect”. ref, interface, and null-adjoined
> types ar
- Mail original -
> De: "Brian Goetz"
> À: "Doug Lea"
> Cc: "valhalla-spec-experts"
> Envoyé: Mardi 9 Avril 2019 19:04:36
> Objet: Re: generic specialization design discussion
> OK, let’s make this problem a little simpler. The question of terminology in
> the JVMS is harder, but we ha
There is another style of attack, inline classes are subject to tearing, so you
can be able to forge an invalid value (with respect to the constructor checks)
of an inline class from two other valid values.
By example,
import java.util.stream.IntStream;
public @__value__ class SecurityToken {
> De: "Brian Goetz"
> À: "valhalla-spec-experts"
> Envoyé: Jeudi 11 Avril 2019 21:52:23
> Objet: Re: Updated VM-bridges document
> This was received through a side channel:
>> From: [ mailto:sebastian.sickelm...@gmx.de | sebastian.sickelm...@gmx.de ]
>> Subject: Re: Updated VM-bridges document
- Mail original -
> De: "Brian Goetz"
> À: "Karen Kinnear"
> Cc: "valhalla-spec-experts"
> Envoyé: Vendredi 12 Avril 2019 01:04:15
> Objet: Re: Updated VM-bridges document
> On 4/11/2019 5:18 PM, Karen Kinnear wrote:
>>>
>>> OK, so at this point, the classfiles that have been loaded
- Mail original -
> De: "Maurizio Cimadamore"
> À: "Brian Goetz" , "valhalla-spec-experts"
>
> Envoyé: Lundi 15 Avril 2019 14:20:35
> Objet: Re: RefObject and ValObject
> On 15/04/2019 13:06, Brian Goetz wrote:
>>
>>
>>> But it seems like we have already ruled this out - since, if
>>> t
> De: "Brian Goetz"
> À: "Maurizio Cimadamore"
> Cc: "valhalla-spec-experts"
> Envoyé: Lundi 15 Avril 2019 16:38:58
> Objet: Re: RefObject and ValObject
>> Let's model the value vs. reference constraint explicitly - e.g. with 'val'
>> and
>> 'ref' type kinds (and let's not open the can worm as
> De: "Brian Goetz"
> À: "Maurizio Cimadamore"
> Cc: "valhalla-spec-experts"
> Envoyé: Lundi 15 Avril 2019 17:23:36
> Objet: Re: RefObject and ValObject
>> Your idea of treating Object as abstract is, I believe, a sound one (which
>> doesn't need any extra rule) - but we might have to figure ou
- Mail original -
> De: "John Rose"
> À: "Brian Goetz"
> Cc: "valhalla-spec-experts"
> Envoyé: Jeudi 18 Avril 2019 23:43:55
> Objet: Re: Valhalla EG notes April 10, 2019
> On Apr 11, 2019, at 1:44 PM, Brian Goetz wrote:
>>
>> To me, getting fancy here sounds like borrowing trouble; it
Hi all,
during a university session at DevoxxFR last Wednesday, we have asked (me and
José Paumard) to the audience if they prefer the keyword 'inline' or
'immediate' to replace 'value' when declaring a 'value' type.
Among the 264 persons that have submitted their answers using Kahoot,
211 vot
I will rain on your parade.
Here, i'm talking about Java the language, not about the VM support of
L/Q-types.
V? is a use site annotation and we all know that use site annotations are the
devil in disguise, wildcards is a good example of a use site feature nobody
understand/want to understand,
Brian ask me to make it its own thread.
so is V? what we need, because i believe we have been a little over our own
head on this and loose the sight of what we need for V?.
we need V?
- to represent the L variation of a Q type.
- to interact with generics that are not reified.
V? does that but d
Actually,
you are more on my side because what i'm proposing make V? less present in
public methods of API, which i think is a good move in term of perf model and
for ArryList, both proposal work the same.
Rémi
- Mail original -
> De: "Doug Lea"
> À: "valhalla-spec-experts"
> Envoyé:
- Mail original -
> De: "Brian Goetz"
> À: "Doug Lea"
> Cc: "valhalla-spec-experts"
> Envoyé: Mercredi 1 Mai 2019 16:39:59
> Objet: Re: Is V? what we need ?
> This is the point I’ve been failing to get across to Remi as well. Suppose
> you
> have a big value, and you want a sparse Arr
I would like to propose an alternative to the V? syntax we are currently using
for representing an inline class encoded as a L-type.
I propose to use Coffer instead of Complex? (with Complex an inline
class).
as notice several of us, the V? syntax as several shortcoming:
- as Brian said, using
Let's say i have this interface:
interface Orderable> {
boolean lessThan(T t);
}
and i want my inline class to implement it:
@__inline__ class FooOrderable implements Orderable {
...
@Override
public boolean lessThan(FooOrderable? foo) {
return false;
}
}
how i'm
Hi Daniel,
section 4.1: in the table 4.1-A,
13/57/45..57 is missing given you talk about later in this section.
section 4.3.2:
I don't think that using null as a diferentiator (Nullable/NonNullable) is a
good idea.
Yes, an inline type is not nullable, but it's also flattenable, loaded early
Hi all, here is my takeaway of the valhalla face to face meeting we had
yesterday.
On the VM side, the model can be simplified by having all classes being either
a Q-type or a L-type but not both at the same time. This will simplify the JVMS
and solve the naming issue i have with Dan because th
Hi all,
We (Maurizio, John and i) have spent some time to play with another proposal of
what LW10 can be based on the "confinent" idea i.e. an inine type can not
appear in a public API and you need an interface to use it in erased generics.
So the idea is to have at Java language level a constr
sion retuning a box while the inline class version returning the
inline class (which is fine because it's a subtype),
otherwise when you call a method of the inline class the result is the box so
you are loosing the non-null property when chaining calls.
with Option the inline class and Optio
- Mail original -
> De: "Remi Forax"
> À: "Brian Goetz"
> Cc: "valhalla-spec-experts"
> Envoyé: Samedi 3 Août 2019 19:48:01
> Objet: Re: Collapsing the requirements
> - Mail original -
>> De: "Brian Goetz"
>&
> De: "Brian Goetz"
> À: "Frederic Parain"
> Cc: "valhalla-spec-experts"
> Envoyé: Mardi 6 Août 2019 18:50:26
> Objet: Re: Collapsing the requirements
>> So, legal signatures will be:
>> - QV;
>> - LI;
>> and that’s it, right?
>> Q will continue to have its current semantic (flattenable, non-n
I think we should take a step back on that subject,
because you are all jumping to the conclusion too fast in my opinion.
Let starts by the beginning,
the question about supporting == on inline type should first be guided by what
we should have decided if inline types were present from the incept
Hi all,
i think the current generated classfile bytecodes can be improved.
For a record Point(int x, int y) { }
The classfile contains:
- a specific class attribute Record
Record:
int x;
descriptor: I
int y;
descriptor: I
which allows compiler separate compilatio
sorry wrong list.
Rémi
- Mail original -
> De: "Remi Forax"
> À: "valhalla-spec-experts"
> Envoyé: Dimanche 1 Septembre 2019 17:27:13
> Objet: Record classfile and runtime API
> Hi all,
> i think the current generated classfile bytecodes can be i
Hi Brian,
really nice write-up.
I've not a lot to say apart about IdentityObject and InlineObject because I
fully agree on the major points (and i've promised to not tak about == but wait
and see instead).
As we briefly talk last Wednesday, i believe there is a less disruptive way to
add Identi
- Mail original -
> De: "Brian Goetz"
> À: "Maurizio Cimadamore" ,
> "valhalla-spec-experts"
>
> Envoyé: Lundi 16 Décembre 2019 15:27:59
> Objet: Re: Lifting operations from inline classes to reference projections
>>
>> I'm not too worried about having a V.ref with its own members - aft
It occurs to me that we may have jump into the conclusion that we should use
inheritance/implementation a little to fast.
At least, i think it worth exploring another complementary option.
In Java, you have several ways to have subtyping,
saying a FooInline is a subclass FooInline.ref is one way,
In the context of Java, we are already using the term 'atomic', in
AtomicInteger, AtomicLong, etc,
and in that case the semantics is volatile + atomic operations (at least CAS),
so i think using atomic or any keyword derived from it will not help to our
users to understand the semantics for an
Hi all,
sorry, was not available for the meeting today (i'm officially on vacation).
I prefer (2) with a restriction like (1).
I don't think users should be able to declare this kind of abstract class
because you can not evolve them easily. I'm worried that if they become a tool
available, peop
> De: "Brian Goetz"
> À: "valhalla-spec-experts"
> Envoyé: Mercredi 19 Février 2020 17:45:38
> Objet: Locking on primitive boxes
> One of the main impediments to migrating the primitive wrappers to be the
> reference projection of an inline class is locking -- there may be code out
> there that
[Moving to valhalla-spec-experts]
- Mail original -
> De: "John Rose"
> À: "Tobias Hartmann"
> Cc: "valhalla-dev"
> Envoyé: Vendredi 21 Février 2020 11:23:14
> Objet: Re: for review: 8236522: "always atomic" modifier for inline classes
> to enforce atomicity
> I’ve come back around to
Hi,
currently a record can only be an IdentityObject but at some point, we want to
introduce an inline record ?
Now the question: What the subtyping relation between java.lang.Record and
InlineObject/IdentityObject ?
An identity record (resp. an inline record) should be a subtype of both
java.
> De: "Brian Goetz"
> À: "valhalla-spec-experts"
> Envoyé: Vendredi 27 Mars 2020 20:59:38
> Objet: Updated SoV documents
> I've updated the SoV documents, including the new sections on VM model and
> translation:
> [ http://cr.openjdk.java.net/~briangoetz/valhalla/sov/01-background.html |
> htt
I don't fully understand why not using checkcast because from the user POV the
message will be better than just NPE.
Rémi
- Mail original -
> De: "John Rose"
> À: "Brian Goetz"
> Cc: "valhalla-spec-experts"
> Envoyé: Jeudi 9 Avril 2020 22:16:06
> Objet: Re: null checks vs. class resol
- Mail original -
> De: "Frederic Parain"
> À: "valhalla-spec-experts"
> Envoyé: Lundi 13 Avril 2020 15:24:18
> Objet: Re: null checks vs. class resolution, and translation strategy for
> casts
>> On Apr 8, 2020, at 14:43, John Rose wrote:
>>
>> I have a proposal for a translation str
> De: "Brian Goetz"
> À: "Tobi Ajila"
> Cc: "valhalla-spec-experts" ,
> "valhalla-spec-experts"
> Envoyé: Vendredi 19 Juin 2020 20:18:09
> Objet: Re: Evolving the wrapper classes
> Zooming out, what we've been trying to do is shake out the places where the
> JVM
> treats primitives and referen
>From valhalla-spec-observers,
- Mail original -
> De: "Gernot Neppert"
> À: "Valhalla Expert Group Observers"
>
> 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
So the default value may a valid value or may be an invalid value,
if it's an invalid value it should be the author of the class that say that
because in Java we prefer declaration site to use site.
One way is to try to teach the VM how to do the conversions, i want to explore
another way where
- Mail original -
> De: "Brian Goetz"
> À: "John Rose"
> Cc: "valhalla-spec-experts"
> Envoyé: Samedi 1 Août 2020 16:41:11
> Objet: Re: no good default issue
>> Personally, I view such tactics as possible but expensive,
>> and would like to try to get by without JVM support for
>> them,
I will still be on the road :)
following the JEP draft, I wonder if all functional interfaces (at least the
ones tagged with @FunctionalInterface) should also be considered as inline
candidates, so synchronizing on them should report a warning too.
the other question is how to declare your own
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 :)
RestrictedField ?
https://bugs.openjdk.java.net/browse/JDK-8254022
Rémi
- Mail original -
> De: "daniel smith"
> À: "valhalla-spec-experts"
> Envoyé: Mercredi 7 Octobre 2020 16:28:55
> Objet: EG meeting, 2020-10-07
> The next EG Zoom meeting is today at 4pm UTC (9am PDT, 12pm EDT).
>
- Mail original -
> De: "daniel smith"
> À: "valhalla-spec-experts"
> Envoyé: Mardi 27 Octobre 2020 20:27:39
> Objet: Re: Source code analysis: calls to wrapper class constructors
>> On Oct 19, 2020, at 6:01 PM, Dan Smith wrote:
>>
>> In the context of the Warnings for Value-Based Clas
- Mail original -
> De: "John Rose"
> À: "daniel smith"
> Cc: "valhalla-spec-experts"
> Envoyé: Mercredi 28 Octobre 2020 05:56:29
> Objet: Re: Source code analysis: calls to wrapper class constructors
> On Oct 27, 2020, at 12:27 PM, Dan Smith wrote:
>>
>> This tooling will support com
- Mail original -
> De: "daniel smith"
> À: "valhalla-spec-experts"
> Envoyé: Mercredi 4 Novembre 2020 19:18:02
> Objet: Re: EG meeting, 2020-11-04
>> On Nov 3, 2020, at 4:53 PM, Dan Smith wrote:
>>
>> The next EG Zoom meeting is Wednesday, 5pm UTC (12pm EST, 9am PST).
>>
>> We'll tal
Using a condy that returns a String instead of a method descriptor in the
bytecode ?
I'm currently trying to remove the uses of Unsafe.defineAnonymousClass to use
Lookup.defineHiddenClass instead.
There is one case where i dynamically patch a method descriptor so I can select
how many arguments
Most of the error message form the error that can be thrown by classes of
java.lang.invoke are using Class.getSimpleName() which makes debugging hidden
classes painful because getSimpleName() scrubs the hexadecimal number part of a
hidden class name.
It also seems that the VM has a zealot stanc
Hi all,
currently an inline record like this
public @__inline__ record IntBox(int value) {
}
generates two classes, IntBox and IntBox$ref, IntBox being the record itself
and IntBox$ref being the abstract class representing the nullable version of an
inline that inherits from java.lang.Record
cool !
Rémi
- Mail original -
> De: "daniel smith"
> À: "valhalla-spec-experts"
> Envoyé: Mercredi 10 Mars 2021 17:12:46
> Objet: EG meeting, 2021-03-10
> The next EG Zoom meeting is today at 5pm UTC (9am PST, 12pm EST).
>
> No new email threads, but John would like to spend some time
Hi all,
slowly reading the Parametric-vm spec.
With my ASM hat,
"As a structural constraint, it is illegal for a CONSTANT_Parameter constant to
be unused."
This is different of all other CONSTANTs and doesn't work well with the idea
that you can patch a classfile by copying the existing constan
In the sub-section "other upcalls",
for type-testing, the VM does an upcall to the method "isAssignableFrom" of the
Species but it's not clear for me how a user can creates such "Species" given
that it seems that the way to configure a species is to return a
ParameterBinding properly configured.
I wonder if the ParameterBinding should not have kind of name or at least a
textual representation so you can see them in stacktraces,
it will be really helpful for debugging.
Rémi
Hi all,
at least as an exercise to understand the proposed class file format for the
parametric VM, i will update ASM soon (in a branch) to see how things work.
As usual with ASM, there is the question of sharing the same index in the
constant pool,
i.e. should two anchors (SpecializationAnchor)
If it's possible, i would like to discuss about IdentityClass again.
As noted in the last draft, adding IdentityClass automatically at runtime is
not a compatible change if tests that uses Class::getInterfaces() are not
written correctly,
and sadly, a lot of tests are written that way. I'm guilt
- Mail original -
> De: "daniel smith"
> À: "valhalla-spec-experts"
> Envoyé: Mercredi 5 Mai 2021 16:23:08
> Objet: EG meeting, 2021-05-05
> The next EG Zoom meeting is today at 4pm UTC (9am PDT, 12pm EDT).
>
> Topics to discuss:
>
> "consolidated VM notes for primitive classes": Updat
java.lang.Object;
Rémi
- Mail original -
> De: "Remi Forax"
> À: "valhalla-spec-experts"
> Envoyé: Mercredi 5 Mai 2021 16:39:01
> Objet: Meeting today: IdentityClass
> If it's possible, i would like to discuss about IdentityClass again.
>
> As
I think there is a way to avoid all the issues we have with new Object().
The problem:
We want to inject the interface IdentityObject on all classes that are
neither a "no field" abstract class nor a primtive class.
But java.lang.Object acts as a "no field" abstract class but it's not an
abs
> De: "Brian Goetz"
> À: "Dan Heidinga"
> Cc: "daniel smith" , "valhalla-spec-experts"
>
> Envoyé: Samedi 5 Juin 2021 17:21:11
> Objet: Re: [External] : Re: Making Object abstract
> Rampdown is next week; time is fleeting.
> I think the path of adding Objects::newIdentity in 17 seems the best
- Mail original -
> De: "daniel smith"
> À: "valhalla-spec-experts"
> Envoyé: Vendredi 4 Juin 2021 19:11:11
> Objet: Re: JEP draft: Better-defined JVM class file validation
>> On Jun 4, 2021, at 10:41 AM, Dan Smith wrote:
>>
>> Posted a new JEP draft, here:
>>
>> http://openjdk.java.n
- Mail original -
> De: "John Rose"
> À: "Brian Goetz"
> Cc: "daniel smith" , "valhalla-spec-experts"
>
> Envoyé: Mercredi 16 Juin 2021 23:50:35
> Objet: Re: Making Object abstract
> On Jun 2, 2021, at 7:57 AM, Brian Goetz wrote:
>>
>> A minor bikeshed comment: We're asking users to
> From: "Brian Goetz"
> To: "valhalla-spec-experts"
> Sent: Mercredi 23 Juin 2021 17:13:27
> Subject: JEP 401 -- reflection and class literals
> In working through the details of reflective support in JEP 401, I think we've
> fallen into a slight "false consistency" regarding class literals. (Th
- Original Message -
> From: "Brian Goetz"
> To: "Peter Levart"
> Cc: "valhalla-spec-experts"
> Sent: Dimanche 27 Juin 2021 22:01:21
> Subject: Re: [External] : Re: JEP 401 -- reflection and class literals
>>
>>
>> Seems like we are forced to re-use Class objects to hold this
>> additio
> From: "Brian Goetz"
> To: "valhalla-spec-experts"
> Sent: Mardi 29 Juin 2021 18:48:25
> Subject: Re: JEP 401 -- reflection and class literals
> The general consensus here is that this stacking is slightly better than the
> previous one, so let's take this as the plan of record. Now, to explore
- Original Message -
> From: "daniel smith"
> To: "valhalla-spec-experts"
> Cc: "Roger Riggs"
> Sent: Lundi 19 Juillet 2021 19:59:03
> Subject: Objects.newIdentity update
[I've added Mark in CC]
> An update on Objects.newIdentity for Java 17: Roger did some work to put the
> feature to
I will take the scenic road to answer :)
There is currently an issue with the fact that we present primitive class as
constructor in Java the language but is translated not to a constructor in the
class file.
This introduce a false sense of compatibility, the code is identical if it's a
classic
- Original Message -
> From: "Brian Goetz"
> To: "daniel smith" , "Dan Heidinga"
>
> Cc: "valhalla-spec-experts"
> Sent: Vendredi 10 Septembre 2021 20:25:50
> Subject: Re: Factory methods & the language model
>> I'm not particularly interested in settling on a bikeshed color, but am
>>
- Original Message -
> From: "daniel smith"
> To: "valhalla-spec-experts"
> Sent: Mardi 5 Octobre 2021 01:34:37
> Subject: Addressing the full range of use cases
> When we talk about use cases for Valhalla, we've often considered a very broad
> set of class abstractions that represent im
Sadly, i will not be able to attend this meeting :(
regards,
Rémi
- Original Message -
> From: "daniel smith"
> To: "valhalla-spec-experts"
> Sent: Mercredi 6 Octobre 2021 00:52:20
> Subject: EG meeting, 2021-10-06
> EG Zoom meeting tomorrow, Wednesday October 6, at 4pm UTC (9am PDT, 1
On October 6, 2021 10:07:09 AM UTC, Maurizio Cimadamore
wrote:
>
>On 06/10/2021 10:56, Remi Forax wrote:
>>> - Existing class types like LocalDate are both nullable and atomic. These
>>> are
>>> useful properties to preserve during migration; nullability, in
I've sent a mail about considering all primitive types as always nullable on
stack (as parameters or local variables).
Rémi
- Original Message -
> From: "daniel smith"
> To: "valhalla-spec-experts"
> Sent: Mercredi 20 Octobre 2021 16:03:12
> Subject: EG meeting *canceled*, 2021-10-20
I really like this, it's far better than how i was seeing Valhalla, pushing
.ref into a corner is a good move.
I still hope that moving from B1 to B2 can be almost backward compatible, if no
direct access to the constructor, no synchronized and reasonable uses of ==.
My only concern now is th
> From: "Kevin Bourrillion"
> To: "Brian Goetz"
> Cc: "valhalla-spec-experts"
> Sent: Jeudi 4 Novembre 2021 22:34:54
> Subject: Re: identityless objects and the type hierarchy
> On Wed, Nov 3, 2021 at 12:43 PM Brian Goetz < [ mailto:brian.go...@oracle.com
> |
> brian.go...@oracle.com ] > wrote
> From: "John Rose"
> To: "daniel smith"
> Cc: "Kevin Bourrillion" , "Brian Goetz"
> , "valhalla-spec-experts"
>
> Sent: Jeudi 4 Novembre 2021 02:34:52
> Subject: Re: [External] : Re: Consolidating the user model
> On Nov 3, 2021, at 4:05 PM, Dan Smith < [ mailto:daniel.sm...@oracle.com |
> dan
> From: "Brian Goetz"
> To: "Kevin Bourrillion"
> Cc: "Dan Heidinga" , "daniel smith"
> , "valhalla-spec-experts"
>
> Sent: Jeudi 18 Novembre 2021 23:34:51
> Subject: Re: EG meeting, 2021-11-17
> I think it is reasonable to consider allowing bucket two classes to be
> abstract.
> They could be
Hi Daniel,
this is really nice.
Here are my remarks.
"It generally requires that an object's data be located at a fixed memory
location"
remove "fixed", all OpenJDK GCs move objects.
Again later, remove "fixed" in "That is, a value object does not have a fixed
memory address ...".
At the begin
> From: "John Rose"
> To: "daniel smith"
> Cc: "Dan Heidinga" , "valhalla-spec-experts"
>
> Sent: Jeudi 2 Décembre 2021 00:56:02
> Subject: Re: [External] : Re: JEP update: Value Objects
> On Dec 1, 2021, at 3:29 PM, Dan Smith < [ mailto:daniel.sm...@oracle.com |
> daniel.sm...@oracle.com ] > w
> From: "John Rose"
> To: "Brian Goetz"
> Cc: "valhalla-spec-experts" , "clement
> cherlin"
> Sent: Thursday, December 9, 2021 5:30:50 AM
> Subject: Re: Proposal: Static/final constructors for bucket-3 primitive
> classes.
> We have considered, at various points in the last six years or more,
> From: "Kevin Bourrillion"
> To: "valhalla-spec-experts"
> Sent: Mercredi 15 Décembre 2021 19:42:55
> Subject: We have to talk about "primitive".
> (Okay, so we're doing this)
> I think the rename to "primitive classes" happened during my outage last year.
> When I came back I made the decision
Brian,
the last time we talked about IdentityObject and ValueObject, you said that you
were aware that introducing those interfaces will break some existing codes,
but you wanted to know if it was a lot of codes or not.
So i do not understand now why you want to mix IdentityObject/ValueObject
> From: "Brian Goetz"
> To: "valhalla-spec-experts"
> Sent: Thursday, December 23, 2021 6:14:43 PM
> Subject: Updated State of Valhalla documents
> Just in time for Christmas, the latest State of Valhalla is available!
> [
> https://openjdk.java.net/projects/valhalla/design-notes/state-of-valha
It just occurs to me that while ACC_VALUE is a bit that change the runtime
semantics,
something the VM should take care of, ACC_PRIMITIVE is not a bit that change the
runtime semantics, only the javac translation strategy,
javac emits Q-types instead of L-type + the Preload attribute.
If value cl
- Original Message -
> From: "Remi Forax"
> To: "valhalla-spec-experts"
> Sent: Thursday, January 6, 2022 7:50:54 PM
> Subject: Why do we need .ref class for primtive class ?
> It just occurs to me that while ACC_VALUE is a bit that change the runt
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 ne
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
ref
I think we should revisit the idea of having the interfaces
IdentityObject/ValueObject.
They serve two purposes
1/ documentation: explain the difference between an identity class and a value
class
2/ type restriction: can be used as type or bound of type parameter for
algorithms that only wor
- Original Message -
> From: "Dan Heidinga"
> To: "daniel smith"
> Cc: "valhalla-spec-experts"
> Sent: Thursday, January 27, 2022 4:09:58 PM
> Subject: Re: SoV-3: constructor questions
> (Resending as I forgot to CC the list - Sorry for the duplicate email Dan)
>
>> We can come up with
- Original Message -
> From: "Dan Heidinga"
> To: "Brian Goetz"
> Cc: "valhalla-spec-experts"
> Sent: Wednesday, February 9, 2022 5:50:29 PM
> Subject: Re: SoV-2: weak references
> One option is to look at what we can do to help users prepare for IAE
> when using value-based classes as
> From: "John Rose"
> To: "daniel smith"
> Cc: "valhalla-spec-experts"
> Sent: Wednesday, February 9, 2022 7:32:07 PM
> Subject: Re: EG meeting, 2022-02-09 [SoV-3: constructor questions]
> On 8 Feb 2022, at 19:04, Dan Smith wrote:
>> "SoV-3: constructor questions": Dan asked about validation f
- Original Message -
> From: "John Rose"
> To: "Frederic Parain"
> Cc: "valhalla-spec-experts"
> Sent: Thursday, February 10, 2022 12:02:53 AM
> Subject: Re: Abstract class with fields implementing ValueObject
> That could be one of very many edge conditions in the JVMS that are not
> d
- Original Message -
> From: "Dan Heidinga"
> To: "daniel smith"
> Cc: "valhalla-spec-experts"
> Sent: Thursday, February 24, 2022 4:39:52 PM
> Subject: Re: Evolving instance creation
> Repeating what I said in the EG meeting:
>
> * "new" carries the mental model of allocating space.
Hi Brian,
i've maybe have twisted mind but i read your email as a rebuttal of both
IdentityObject/ValueObject and identity/value modifiers.
As you said, an identity object and a value object are less dis-similar now
that they were in the past: a value class now reuse the method equals and
has
- Original Message -
> From: "Maurizio Cimadamore"
> To: "daniel smith" , "valhalla-spec-experts"
>
> Sent: Wednesday, March 23, 2022 11:23:26 AM
> Subject: Re: Alternative to IdentityObject & ValueObject interfaces
> On 22/03/2022 23:56, Dan Smith wrote:
>> Other abstract classes and i
> From: "Brian Goetz"
> To: "daniel smith" , "valhalla-spec-experts"
>
> Sent: Thursday, March 24, 2022 1:46:44 PM
> Subject: Re: Alternative to IdentityObject & ValueObject interfaces
> On 3/23/2022 10:51 PM, Dan Smith wrote:
>>> On Mar 22, 2022, at 5:56 PM, Dan Smith < [ mailto:daniel.sm...@o
- Original Message -
> From: "Dan Heidinga"
> To: "Brian Goetz"
> Cc: "daniel smith" , "valhalla-spec-experts"
>
> Sent: Friday, April 1, 2022 3:50:20 PM
> Subject: Re: Object as a concrete class
> On Fri, Apr 1, 2022 at 9:29 AM Brian Goetz wrote:
>>
>>
>> > assert new Object().hasIde
> From: "Kevin Bourrillion"
> To: "valhalla-spec-experts"
> Sent: Saturday, April 23, 2022 12:38:12 AM
> Subject: Objects vs. values, the continuation
> I'd like to remind everyone about this (self-important-sounding) document I
> shared some months ago: [
> https://docs.google.com/document/d/1J
201 - 300 of 318 matches
Mail list logo
