Re: Anonymous value classes

> On Jun 4, 2022, at 3:33 AM, fo...@univ-mlv.fr wrote: > > there is a lot of libraries that have APIs using interfaces that are > implemented by anonymous classes, the collection API is one of them, fluent > loggers (anything fluent in fact) is another, and those will benefit to have > better

Re: Anonymous value classes

> On Jun 3, 2022, at 10:15 AM, Dan Smith wrote: > > Our javac prototype has long included support for a 'value' keyword after > 'new' to indicate that an anonymous class is a value class (I see Remi brought this up in the list in July 2018, which is probably what inspired t

Anonymous value classes

Our javac prototype has long included support for a 'value' keyword after 'new' to indicate that an anonymous class is a value class: Runnable r = new value Runnable() { public void run() { x.foo(); } }; Is this something we'd like to preserve as a language feature? Arguments for: -

EG meeting *canceled*, 2022-06-01

Not much recent traffic, let's cancel today. Kevin had some comments about == and pre-migration warnings that are worth your attention if you haven't reviewed that thread...

Re: Spec change documents for Value Objects

On Apr 27, 2022, at 5:01 PM, Dan Smith mailto:daniel.sm...@oracle.com>> wrote: Please see these two spec change documents for JLS and JVMS changes in support of the Value Objects feature. Here's a revision, including some additional language checks that I missed in the first iteration.

Re: EG meeting, 2022-05-18

> On May 18, 2022, at 8:24 AM, Dan Smith wrote: > > EG Zoom meeting today at 4pm UTC (9am PDT, 12pm EDT). > > Recent threads to discuss: > > - "User model stacking: current status": Brian talked about factoring > atomicity out of the B2/B3 choice,

EG meeting, 2022-05-18

EG Zoom meeting today at 4pm UTC (9am PDT, 12pm EDT). Recent threads to discuss: - "User model stacking: current status": Brian talked about factoring atomicity out of the B2/B3 choice, as an extra choice applying to B3 (and perhaps B2, too) - "Nullity (was: User model stacking: current

Re: Nullity (was: User model stacking: current status)

> On May 11, 2022, at 7:45 PM, Kevin Bourrillion wrote: > > * `String!` indicates "an actual string" (I don't like to say "a non-null > string" because *null is not a string!*) The thread talks around this later, but... what do I get initially if I declare a field/array component of type

Re: User model stacking: current status

> On May 9, 2022, at 10:10 AM, Kevin Bourrillion wrote: > >>> But seriously, we won't get away with pretending there are just 3 buckets >>> if we do this. Let's be honest and call it B4. >> "Bucket" is a term that makes sense in language design, but need not flow >> into the user model. But

Re: User model stacking: current status

> On May 6, 2022, at 8:04 AM, Brian Goetz wrote: > > Thinking more about Dan's concerns here ... > > On 5/5/2022 6:00 PM, Dan Smith wrote: >> This is significant because the primary reason to declare a B2 rather than a >> B3 is to guarantee that the all-ze

Re: User model stacking: current status

> On May 5, 2022, at 1:21 PM, Brian Goetz wrote: > > Let's write this out more explicitly. Suppose that T1 writes a non-null > value (d, t, true), and T2 writes null as (0, 0, false). Then it would be > possible to observe (0, 0, true), which means that we would be conceivably > exposing

EG meeting, 2022-05-04

EG Zoom meeting today at 4pm UTC (9am PDT, 12pm EDT). We've had a flurry of activity in the last couple of weeks. I think we can summarize as follows: - "Spec change documents for Value Objects": revised JVMS to align with previous discussions about Value Objects, and a new JLS changes

Re: User model stacking

> On Apr 27, 2022, at 7:36 PM, Kevin Bourrillion wrote: > > This is kinda reading as... > > * First we have 3 buckets > * But people ask if there could be just 2 buckets > * No, so let's have 5 buckets. > > I don't understand why this is happening, but I take it back! I take back > what I

Spec change documents for Value Objects

Please see these two spec change documents for JLS and JVMS changes in support of the Value Objects feature. http://cr.openjdk.java.net/~dlsmith/jep8277163/jep8277163-20220427/specs/value-objects-jls.html

Re: [External] Foo / Foo.ref is a backward default; should be Foo.val / Foo

On Apr 26, 2022, at 5:22 PM, Kevin Bourrillion mailto:kev...@google.com>> wrote: (Thought experiment: if we had an annotation meaning "using the .val type is not a great idea for this class and you should get a compile-time warning if you do" would we really and I mean *really* even need

Re: Foo / Foo.ref is a backward default; should be Foo.val / Foo

On Apr 26, 2022, at 12:37 PM, Dan Heidinga mailto:heidi...@redhat.com>> wrote: The question again is what's the primary reason(s) for exposing a B3 (.val) vs B2 instance in APIs? What guidance would we give API designers around the use of B3 .val instances? So one piece of guidance we could

Re: We need help to migrate from bucket 1 to 2; and, the == problem

On Apr 26, 2022, at 8:22 AM, Kevin Bourrillion mailto:kev...@google.com>> wrote: It's a great start, but the key difference is that we need to be able to apply this process to *our own* types, not just the JDK types. Really, we should see whatever we need to do for JDK types as a clue to what

Re: B3 ref model

On Apr 26, 2022, at 9:19 AM, fo...@univ-mlv.fr wrote: For me, L-type means: if you do not already know, you will discover later if it's a B1/B2/B3 when the class will be loaded. The preload attribute means: if you do not already know, you should load the class now (at

Re: Foo / Foo.ref is a backward default; should be Foo.val / Foo

On Apr 26, 2022, at 8:45 AM, Kevin Bourrillion mailto:kev...@google.com>> wrote: I think I would insist that `.val` be spelled with only one additional character... or even that the value type be generated as the snake_case form of the name! Okay, this is a meaningful refinement that I find

Re: Foo / Foo.ref is a backward default; should be Foo.val / Foo

On Apr 25, 2022, at 8:20 PM, Kevin Bourrillion mailto:kev...@google.com>> wrote: On Mon, Apr 25, 2022 at 7:52 PM Dan Smith mailto:daniel.sm...@oracle.com>> wrote: Yeah, I think this has to be the starting place, before we get into whatever other model simplifications, compatibl

Re: B3 ref model

> On Apr 25, 2022, at 3:08 PM, Remi Forax wrote: > > Ok, maybe i've not understood correctly how B3 model works, > for me being a B3 is a runtime property, not a type property. > > By example, if there is an Object but the VM knows the only possible type is > a B3 and the value is not null

Re: Foo / Foo.ref is a backward default; should be Foo.val / Foo

On Apr 25, 2022, at 8:05 AM, Brian Goetz mailto:brian.go...@oracle.com>> wrote: Let’s state the opposing argument up front, because it was our starting point: having to say “Complex.val” for 99% of the utterances of Complex would likely be perceived as “boy those Java guys love their

EG meeting *canceled*, 2022-04-20

No new email threads, we'll cancel this time.

EG meeting, 2022-04-06

Sorry, missed putting this mail together earlier. Planning to meet today, I'll be a little late. Let's plan on starting about 15 minutes after. Thanks, Dan

Re: Alternative to IdentityObject & ValueObject interfaces

On Mar 22, 2022, at 10:52 PM, Dan Smith mailto:daniel.sm...@oracle.com>> wrote: On Mar 22, 2022, at 7:21 PM, Dan Heidinga mailto:heidi...@redhat.com>> wrote: A couple of comments on the encoding and questions related to descriptors. JVM proposal: - Same conceptual framework. -

Object as a concrete class

One of our requirements has been that 'new Object()' must be re-interpreted (both at compile time and run time) to instantiate some other class—Object is effectively abstract. The motivation here is that every class instance must be identified as an identity object or a value object, and the

Re: Alternative to IdentityObject & ValueObject interfaces

On Mar 22, 2022, at 5:56 PM, Dan Smith mailto:daniel.sm...@oracle.com>> wrote: - Variable types: I don't see a good way to get the equivalent of an 'IdentityObject' type. It would involve tracking the 'identity' property through the whole type system, which seems like a huge

EG meeting, 2022-03-23

EG Zoom meeting today at *4pm* UTC (9am PDT, 12pm EDT). Thanks for the feedback in the "Alternative to IdentityObject & ValueObject interfaces" thread. We can continue that discussion.

Re: Alternative to IdentityObject & ValueObject interfaces

On Mar 22, 2022, at 7:44 PM, Kevin Bourrillion mailto:kev...@google.com>> wrote: On Tue, Mar 22, 2022 at 4:56 PM Dan Smith mailto:daniel.sm...@oracle.com>> wrote: In response to some encouragement from Remi, John, and others, I've decided to take a closer look at how we mi

Re: Alternative to IdentityObject & ValueObject interfaces

On Mar 22, 2022, at 7:21 PM, Dan Heidinga mailto:heidi...@redhat.com>> wrote: A couple of comments on the encoding and questions related to descriptors. JVM proposal: - Same conceptual framework. - Classes can be ACC_VALUE, ACC_IDENTITY, or neither. - Legacy-version classes are implicitly

Alternative to IdentityObject & ValueObject interfaces

In response to some encouragement from Remi, John, and others, I've decided to take a closer look at how we might approach the categorization of value and identity classes without relying on the IdentityObject and ValueObject interfaces. (For background, see the thread "The interfaces

EG meeting *canceled*, 2022-03-09

Only list traffic since last meeting is a couple of followups to that discussion, so I think we can skip this time. Next meeting March 23.

Re: Evolving instance creation

On Mar 1, 2022, at 6:56 AM, Kevin Bourrillion mailto:kev...@google.com>> wrote: The main thing I think CICEs/`new` accomplish is simply to "cross the bridge". Constructors are void and non-static; yet somehow we need to call them as if they're static and non-void! `new` gets us across that

Re: Evolving instance creation

> On Feb 24, 2022, at 8:47 AM, Remi Forax wrote: > > - 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

Re: Abstract class with fields implementing ValueObject

TLDR: I'm convinced, let's revise our approach so that the JVM never infers interfaces for abstract classes. On Feb 24, 2022, at 8:57 AM, Dan Heidinga mailto:heidi...@redhat.com>> wrote: Whether they can be instantiated is a decision better left to other parts of the spec (in this case, I

Re: Abstract class with fields implementing ValueObject

Fred suggested that we enumerate the whole space here. So, some cases to consider: { ACC_PERMITS_VALUE, not } { has an declaration, not } { implements IdentityObject, not } { implements ValueObject, not } "implements" here refers to both direct and indirect superinterfaces. I'll focus on the

EG meeting, 2022-02-23

EG Zoom meeting today at 5pm UTC (9am PDT, 12pm EDT). Potential topics: "Evolving instance creation": I discussed considerations for how we evolve class instance creation expressions in the language "Abstract class with fields implementing ValueObject": discussion about a bytecode validation

Evolving instance creation

One of the longstanding properties of class instance creation expressions ('new Foo()') is that the instance being produced is unique—that is, not '==' to any previously-created instance. Value classes will disrupt this invariant, because it's possible to "create" an instance of a value class

Re: Abstract class with fields implementing ValueObject

> On Feb 14, 2022, at 7:23 AM, Frederic Parain > wrote: > > > On 2/13/22 1:05 PM, Dan Smith wrote: >>> On Feb 12, 2022, at 10:16 PM, Srikanth Adayapalam >>> wrote: >>> >>> I understand Frederic is asking about whether the spec​ inadvertentl

Re: Abstract class with fields implementing ValueObject

> On Feb 9, 2022, at 2:50 PM, Frederic Parain > wrote: > > There's a weird case that seems to be allowed by the Value Objects JVMS draft: > > An abstract class can declare non-static fields, which means it won't > have the ACC_PERMITS_VALUE flag set, but also declare that it implements > the

Re: EG meeting, 2022-02-09 [SoV-3: constructor questions]

I need to do more work and have something concrete to propose before engaging too deeply in this discussion, but: > On Feb 9, 2022, at 11:32 AM, John Rose wrote: > > Regarding reflection, I think it would be OK to surface all of the > methods (of whatever signature) on the getConstructors

EG meeting, 2022-02-09

EG Zoom meeting tomorrow at 5pm UTC (9am PDT, 12pm EDT). Some mail discussions we can follow up on: "VM model and aconst_init": we had a side conversation about potentially requiring explicit conversions from Q to L "Interface pollution and JVM invariants": Dan pointed out that the interfaces

Re: Interface pollution and JVM invariants

On Jan 28, 2022, at 2:28 PM, Dan Heidinga mailto:heidi...@redhat.com>> wrote: public WeakReference(T o) { if (o.getClass().isValue()) throw IAE; referent = o; } That kind of check is easy to miss (or assume isn't required) based on a straightforward reading of the source code. I like the

Re: VM model and aconst_init

I'll chime in that I am coming around to disjoint Q/L, and here are a couple of thoughts on how to reconcile that with VM generics. On Jan 27, 2022, at 2:00 PM, John Rose mailto:john.r.r...@oracle.com>> wrote: Furthermore, i believe that subtyping is a key to avoid multiple bytecode

Re: The interfaces IdentityObject and ValueObject must die !

On Jan 26, 2022, at 6:14 PM, John Rose mailto:john.r.r...@oracle.com>> wrote: On 26 Jan 2022, at 16:55, Dan Smith wrote: On Jan 26, 2022, at 4:55 PM, John Rose mailto:john.r.r...@oracle.com>> wrote: Independently of that, for the specific case of Object , having a qu

Re: SoV-3: constructor questions

> On Jan 27, 2022, at 8:09 AM, Dan Heidinga wrote: > >>> 2) What is the rationale behind the return type restrictions on >>> methods? > >> Treatment of methods is still unresolved, so this (and the JEP) is >> just describing one possible approach. I tried to reach a conclusion on this

Re: The interfaces IdentityObject and ValueObject must die !

On Jan 26, 2022, at 4:36 PM, fo...@univ-mlv.fr wrote: But this isn't a property of the *class*, it's a property of the *type*, as used at a particular use site. If you want to know whether an array is flattened, the class of the component can't tell you. The

Re: The interfaces IdentityObject and ValueObject must die !

On Jan 26, 2022, at 2:18 AM, fo...@univ-mlv.fr wrote: In other words: I don't see a use case for distinguishing between primitive and value classes with different interfaces. Primitive classes does not allow nulls and are tearable, following your logic, there should be

EG meeting *canceled*, 2022-01-26

I've got a conflict tomorrow; let's cancel the EG meeting. There are a few ongoing email discussions, in particular about the State of Valhalla documents. If it's still useful, we can pick up those discussions next time.

Re: The interfaces IdentityObject and ValueObject must die !

> On Jan 25, 2022, at 2:39 PM, Remi Forax wrote: > > 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 And, in particular, describe the

JEP update: Classes for the Basic Primitives

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

Terminology bikeshedding summary

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

EG meeting, 2022-01-12

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

Re: Updated State of Valhalla documents

> On Jan 5, 2022, at 5:14 PM, fo...@univ-mlv.fr wrote: > >> But: it's really important to understand that, in the proposed model, >> primitive >> values, identity objects, and value objects *all* belong to classes. > > yes, > for the VM, a lambda, a record or an enum are all classes, even if in

Re: Updated State of Valhalla documents

> On Dec 23, 2021, at 12:58 PM, fo...@univ-mlv.fr wrote: > > But for Java, i would argue that the model is more > we have either reference objects or primitives, for reference objects you > have those with identity and those without identity, > hence "primitive" being a top-level kind while

Re: JEP update: Value Objects

> On Dec 20, 2021, at 10:54 AM, Brian Goetz wrote: > > > So the choices for VM infer seem to be: > > - Only inject IO for legacy concrete classes, based on classfile version, > otherwise require everything to be explicit; > - Inject IO for concrete classes when ACC_VALUE is not present,

JEP update: Primitive Classes

First, I've made some minor revisions to the Value Objects JEP in the last couple of weeks. You can see it here: https://openjdk.java.net/jeps/8277163 Second, I've put together a draft of a revised JEP 401, Primitive Classes. This removes content that became part of the Value Objects feature,

Re: We have to talk about "primitive".

On Dec 15, 2021, at 12:17 PM, Brian Goetz mailto:brian.go...@oracle.com>> wrote: The main problem I think we can't escape is that we'll still need some word that means only the eight predefined types. (For the sake of argument let's assume we can pick one and lean hard on it, whether that's

EG meeting, 2021-12-15

EG Zoom meeting today at 5pm UTC (9am PDT, 12pm EDT). Possible topics: "JEP update: Value Objects": discussed some details about inferred superinterfaces, including impact on JVMTI "basic conceptual model": Kevin shared his notes describing key Java programming model concepts, in anticipation

Re: JEP update: Value Objects

> On Dec 2, 2021, at 1:04 PM, Dan Heidinga wrote: > > On Thu, Dec 2, 2021 at 10:05 AM Dan Smith wrote: >> >> On Dec 2, 2021, at 7:08 AM, Dan Heidinga wrote: >> >> When converting back from our internal form to a classfile for the >> JVMTI Retransform

Re: JEP update: Value Objects

On Dec 2, 2021, at 7:08 AM, Dan Heidinga mailto:heidi...@redhat.com>> wrote: When converting back from our internal form to a classfile for the JVMTI RetransformClasses agents, I need to either filter the interface out if we injected it or not if it was already there. JVMTI's

Re: JEP update: Value Objects

> On Dec 1, 2021, at 4:56 PM, John Rose wrote: > > On Dec 1, 2021, at 3:29 PM, Dan Smith wrote: >> >> So we went down the path of "maybe there's no need for a flag at all" in >> today's meeting, and it might be worth more consideration, but I convinc

Re: JEP update: Value Objects

> On Dec 1, 2021, at 9:32 AM, Remi Forax wrote: > > 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

Re: [External] : Re: JEP update: Value Objects

> On Dec 1, 2021, at 8:48 AM, Dan Heidinga wrote: > >> class file representation & interpretation >> >> A value class is declared in a class file using the ACC_VALUE modifier >> (0x0100). At class load time, the class is considered to implement the >> interface ValueObject; an error occurs

EG meeting, 2021-12-01

EG Zoom meeting today at 5pm UTC (9am PDT, 12pm EDT). We can discuss "JEP update: Value Objects", the use of the term "value" here, and class file encodings.

Re: JEP update: Value Objects

On Nov 30, 2021, at 12:05 AM, John Rose mailto:john.r.r...@oracle.com>> wrote: Also, I’m not really demanding a title change here, Dan, but rather asking everyone to be careful about any presupposition that “of course we will heal the rift by making all primitives be classes”. Or even “all

JEP update: Value Objects

I've been exploring possible terminology for "Bucket 2" classes, the ones that lack identity but require reference type semantics. Proposal: *value classes*, instances of which are *value objects* The term "value" is meant to suggest an entity that doesn't rely on mutation, uniqueness of

Re: [External] : Re: EG meeting, 2021-11-17

> On Nov 22, 2021, at 2:07 PM, Kevin Bourrillion wrote: > >> On Mon, Nov 22, 2021 at 6:27 AM Dan Heidinga wrote: >> >> I'll echo Brian's comment that I'd like to understand Kevin's use >> cases better to see if there's something we're missing in the design / >> a major use case that isn't

Re: [External] : Re: Consolidating the user model

On Nov 4, 2021, at 10:08 AM, Kevin Bourrillion mailto:kev...@google.com>> wrote: Your model is likely enough the best, and I'm simply "resisting" it, but in that case I'm channeling some of the resistance other users will feel, and we can hash out how to head it off. But also, occasionally I

Re: [External] : Re: Consolidating the user model

On Nov 3, 2021, at 7:34 PM, John Rose mailto:john.r.r...@oracle.com>> wrote: There’s a bigger hiccup when you compare all that with good old int: int iv = 42; // “class int” is NOT a thing, but “class Integer” is assert iv.getClass() != int.class; // because int is not a class assert

Re: [External] : Re: Consolidating the user model

On Nov 3, 2021, at 6:19 PM, Kevin Bourrillion mailto:kev...@google.com>> wrote: I think my intuitions about boxes tie heavily to 'getClass' behavior (or some analogous reflective operation). "What are you?" should give me different answers for a bare value and a box. A duck in a box is not the

Re: [External] : Re: Consolidating the user model

On Nov 3, 2021, at 3:40 PM, Kevin Bourrillion mailto:kev...@google.com>> wrote: The problem is that you want to say that the Point gets converted to some other thing, yet that other thing: - is == to the original I would hope that's already true of int==Integer? Formally, you can't literally

Re: Consolidating the user model

On Nov 3, 2021, at 11:23 AM, Kevin Bourrillion mailto:kev...@google.com>> wrote: On Wed, Nov 3, 2021 at 9:02 AM John Rose mailto:john.r.r...@oracle.com>> wrote: > One way to thicken this thin argument is to say that Point is not really a > class. > It’s a primitive. Then it still has a

Re: Equality operator for identityless classes

On Nov 3, 2021, at 9:58 AM, Kevin Bourrillion mailto:kev...@google.com>> wrote: Today, things are pretty okay because developers can learn that `==` is a code smell. A responsible code reviewer has to think through each one like this: 1. Look up the type. Is it a builtin, or Class? Okay, we're

EG meeting, 2021-11-03

EG Zoom meeting today at 4pm UTC (9am PDT, 12pm EDT). Note that we're still on DST in the US, won't shift to 5pm UTC until next time. We'll discuss: "Consolidating the user model": Brian described a user model centered on reference and value types. Sent just yesterday, so we'll probably spend

EG meeting *canceled*, 2021-10-20

No new topics today, so we'll cancel the meeting. Next scheduled slot is November 3.

EG meeting, 2021-10-06

EG Zoom meeting tomorrow, Wednesday October 6, at 4pm UTC (9am PDT, 12pm EDT). We can discuss "Addressing the full range of use cases", which concerns how we support nullability, atomicity, and migration.

Re: Addressing the full range of use cases

as a supplement.) > On Oct 4, 2021, at 5:34 PM, Dan Smith wrote: > > Some questions to consider for this approach: > > - How do we group features into clusters so that they meet the sweet spot of > user expectations and use cases while minimizing complexity? Is two clusters

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 immutable, identity-free data. JEP 401 mentions varieties of integers and floats, points, dates and times, tuples, records, subarrays, cursors, etc. However, as shorthand this

EG meeting, 2021-09-22

Tomorrow's EG Zoom meeting is on! Wednesday at 4pm UTC (9am PDT, 12pm EDT). Topics to discuss: "Factory methods & the language model": I raised some questions about how we think we should treat JVM factory methods in tools/libraries that present a language-level view. "Project status

Project status summary

As I've mentioned, I've been wanting to put together a broad summary of where the project is at. I've grouped this into three areas or tracks: Primitive Objects, Unified Primitives, and Universal Generics. -- Primitive Objects JEP 401: This is the core preview feature, including primitive

Re: Factory methods & the language model

> On Sep 10, 2021, at 7:56 AM, Dan Heidinga wrote: > > On Thu, Sep 9, 2021 at 5:32 PM Dan Smith wrote: >> >> On Sep 9, 2021, at 1:13 PM, Dan Heidinga wrote: >> >> but to keep the door open to having both factories and >> constructors in identity cl

Re: [External] : Re: Factory methods & the language model

On Sep 9, 2021, at 1:13 PM, Dan Heidinga mailto:heidi...@redhat.com>> wrote: but to keep the door open to having both factories and constructors in identity classes, should we use a different syntax for factories in primitive classes now? That way factories would be "spelled" consistently

Re: Factory methods & the language model

approach, although choices we make for the Java language & tools _might_ influence the set of constraints we choose to impose in JVMS. > On Sep 9, 2021, at 10:15 AM, Dan Heidinga wrote: > > On Thu, Sep 9, 2021 at 10:24 AM Dan Smith wrote: >> >> JEP 401 includes sp

Factory methods & the language model

JEP 401 includes special JVM factory methods, spelled (or, alternatively, with a non-void return), which are needed as a standardized way to encode the Java language's primitive class constructors. We have a lot of flexibility in how much we restrict use of these methods. Too many

EG meeting *canceled*, 2021-09-08

Well, I was hoping to be in a place to have a good status update conversation tomorrow, but the long weekend interfered with those plans. I think we'll be best off skipping this meeting once more, and regrouping on Sep 22. In the mean time, if there's anything you think deserves some attention,

Re: [External] : Re: Draft JVMS changes for Primitive Objects (JEP 401)

> On Aug 11, 2021, at 1:24 PM, Dan Heidinga wrote: > > And continuing on the "long-overdue" theme, here's my long-overdue > review of the spec changes. > > A big thank you to you, Dan S., for the careful spec writeup efforts. > I think this captures our discussions well. > > --Dan > > ==

EG meeting *canceled*, 2021-08-25

Eh, still quiet on here. Guess we'll skip one more meeting. I expect we'll have a useful status update by the next one. Carry on! (I owe Dan a reply on JVMS for JEP 401, which I will get to soon.)

EG meeting *canceled*, 2021-08-11

I don't see anything new to discuss, so we'll skip today's meeting. Next meeting: August 25. We're having some good internal discussions about default values & null, and will send something out when that settles into something stable.

EG meeting *canceled*, 2021-07-28

I'm on vacation this coming week, and I think we can defer any topics to next time. Next meeting: August 11.

Objects.newIdentity update

An update on Objects.newIdentity for Java 17: Roger did some work to put the feature together and get it reviewed. https://bugs.openjdk.java.net/browse/JDK-8269096 However, while the implementation is straightforward, for libraries folks not deeply familiar with the Valhalla Project, the

EG meeting, 2021-07-14

The next EG Zoom meeting is Wednesday at 4pm UTC (9am PDT, 12pm EDT). Topics to discuss: "Draft JVMS changes for Primitive Objects (JEP 401)": I shared a revised JVM spec for JEP 401. Some new, tentative ideas here: - "Inlinable reference type" terminology - An ACC_PRIM_SUPER flag - An

Draft JVMS changes for Primitive Objects (JEP 401)

Here's a long-overdue refresh of the proposed JVMS changes to support Primitive Objects: http://cr.openjdk.java.net/~dlsmith/jep401/latest (Sorry to dump this on the weekend, not looking for same-day feedback. :-)) I *think* I've captured all the key JVMS-related pieces that we expect to

EG meeting *canceled*, 2021-06-30

There's been a little bit of traffic on the list, but I've got a conflict today and I think we can defer talking about those things until next time. Next meeting July 14.

Re: Revisiting default values

> On Jun 29, 2021, at 11:54 AM, Kevin Bourrillion wrote: > > Sorry for quietness of late. Glad to have you back! Unfortunately, there's not much new to report in this area, other than the fact that we are aware that more design and prototyping work is needed. Here's an open task to prototype

Re: JEP 401 -- reflection and class literals

> On Jun 23, 2021, at 12:39 PM, Brian Goetz wrote: > > >> We can "fix" this behavior by supporting "fuzzy matching" in the 'getMethod' >> method, so that both Point.val.class and Point.ref.class are considered >> matches for Point.val.class in method signatures. That feels to me like a >>

Re: JEP 401 -- reflection and class literals

> On Jun 23, 2021, at 9:13 AM, Brian Goetz wrote: > > - In the context of a variable type, Point is an alias for Point.val, or > Point.ref, if ref-default (no change from current); > - Where a class is needed (e.g., new Point(), instanceof Point), > Point refers to the class Point,

EG meeting, 2021-06-16

The next EG Zoom meeting is Wednesday at 4pm UTC (9am PDT, 12pm EDT). Topics to discuss: "JEP draft: Better-defined JVM class file validation": I created a JEP for some JVMS fixes and associated behavioral changes related to class file validation "JEP draft: Universal Generics": A JEP covering

JEP draft: Universal Generics

Please see this JEP draft: http://openjdk.java.net/jeps/8261529 This is the third anticipated piece in our initial suite of Valhalla preview features (along with JEPs 401 and 402). It's also the first step in the revised generics story, to be followed up in the future with JVM enhancements for

Re: JEP draft: Better-defined JVM class file validation

> On Jun 6, 2021, at 10:17 AM, Remi Forax wrote: > > - 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

  1   2   3   >