Re: Clarifying record reflective support

Maurizio Cimadamore" > Cc: "Remi Forax" , "Brian Goetz" , > "amber-spec-experts" , "joe darcy" > > Envoyé: Mercredi 4 Décembre 2019 20:20:46 > Objet: Re: Clarifying record reflective support > On Dec 4, 2019, at 7:59 AM, Maurizi

Re: Clarifying record reflective support

> De: "John Rose" > À: "Maurizio Cimadamore" > Cc: "Remi Forax" , "Brian Goetz" , > "amber-spec-experts" , "joe darcy" > > Envoyé: Mercredi 4 Décembre 2019 20:20:46 > Objet: Re: Clarifying record reflective support

Re: Clarifying record reflective support

Short answer: nope. > You are already describing the current situation, we already have methods > that returns null (wrong), > but not all of them so why add a new one ? Heh, this is a “high school debate team” sort of argument — it amounts to “there is already an inconsistency in the world,

Re: Clarifying record reflective support

On 04/12/2019 15:53, fo...@univ-mlv.fr wrote: Like getEnumConstants(), this is an argument i can agree upon. Yes, that is the important precedent here. But during the scanning of the methods of java.lang.Class, i've discovered that describeConstable() already returns an Optional.

Re: Clarifying record reflective support

- Mail original - > De: "Maurizio Cimadamore" > À: "Remi Forax" > Cc: "Chris Hegarty" , "amber-spec-experts" > , "joe darcy" > > Envoyé: Mercredi 4 Décembre 2019 01:26:11 > Objet: Re: Clarifying record reflect

Re: Clarifying record reflective support

On 04/12/2019 00:17, fo...@univ-mlv.fr wrote: I don't follow you, conceptually a pattern matching is an optional of tuples (i don't want to go more deep than that given that the real implementation is still in flux), you can construct an optional if getReturnComponents() returns null or not.

Re: Clarifying record reflective support

> De: "Maurizio Cimadamore" > À: "Remi Forax" , "Chris Hegarty" > > Cc: "amber-spec-experts" , "joe darcy" > > Envoyé: Mardi 3 Décembre 2019 22:40:11 > Objet: Re: Clarifying record reflective support > I fe

Re: Clarifying record reflective support

De: "Chris Hegarty" > À: "amber-spec-experts" , "joe darcy" > , "Maurizio Cimadamore" > > Envoyé: Mardi 3 Décembre 2019 12:26:53 > Objet: Clarifying record reflective support > A number of issues and/or concerns have been come up recently relat

Re: Clarifying record reflective support

On Dec 3, 2019, at 10:36 AM, Dan Smith wrote: > > My general feeling about the reflection API is that it could do a better job > of specifying behavior for the full space of class files, not just those > produced by javac. I wouldn't mind a lot more discussion about class file > artifacts

Re: Clarifying record reflective support

> On Dec 3, 2019, at 10:15 AM, Brian Goetz wrote: > > I am not even sure if “has a record attribute” isn’t overkill. “Is a record > class” is the more proper semantic specification, and it’s not clear to me > that reflection api spec is the place to record these things. If the goal is to

Re: Clarifying record reflective support

On Dec 3, 2019, at 9:06 AM, Alex Buckley wrote: > > What I am trying to do is help Chris understand the JVMS draft so he can ship > in JDK 14 -- is there anything in section 4.7 of the draft that needs to be > changed for JDK 14? No, it’s good! What I’ve written in this thread is to

Re: Clarifying record reflective support

From the point of view of core reflection, I think, “is a record class” is fine. ( which is the wording proposed ) Reflection implicitly relies on the Record attribute to populate the array returned by getRecordComponents ( what else could it do ). I don’t think we need to go further than what

Re: Clarifying record reflective support

On 03/12/2019 17:15, Brian Goetz wrote: I am not even sure if “has a record attribute” isn’t overkill. “Is a record class” is the more proper semantic specification, and it’s not clear to me that reflection api spec is the place to record these things. Should reflection speak about 'has a

Re: Clarifying record reflective support

I am not even sure if “has a record attribute” isn’t overkill. “Is a record class” is the more proper semantic specification, and it’s not clear to me that reflection api spec is the place to record these things. Sent from my MacBook Wheel > On Dec 3, 2019, at 12:12 PM, Alex Buckley wrote:

Re: Clarifying record reflective support

On 12/3/2019 8:49 AM, Dan Smith wrote: So, Fine: "isRecord returns true if the class extends java.lang.Record and has a Record attribute." (a little more detailed than most reflection methods, but that's probably good) Overkill: "isRecord returns true if the class extends java.lang.Record and

Re: Clarifying record reflective support

On 12/3/2019 8:39 AM, John Rose wrote: On Dec 3, 2019, at 8:31 AM, Alex Buckley > wrote: For example, if the Record.components[i].attributes table contains a Signature attribute, then that's fine per Table 4.7-C; but if said table contains a Code attribute,

Re: Clarifying record reflective support

On 12/3/2019 8:35 AM, John Rose wrote: I have two concerns concerning JVM behavior: 1. Keep class file loading fast and simple. Don’t go beyond precedent in structure checking. The current implementation is good from this POV; it just ensures basic referential integrity at the constant pool

Re: Clarifying record reflective support

> On Dec 3, 2019, at 9:35 AM, John Rose wrote: > > I have two concerns concerning JVM behavior: > > 1. Keep class file loading fast and simple. > 2. Perform deeper checks only when reflection is performed. We just discussed on the phone, this is consistent with the consensus. > This subtly

Re: Clarifying record reflective support

On Dec 3, 2019, at 8:31 AM, Alex Buckley wrote: > > For example, if the Record.components[i].attributes table contains a > Signature attribute, then that's fine per Table 4.7-C; but if said table > contains a Code attribute, then the overall Record attribute is malformed, > and I would expect

Re: Clarifying record reflective support

This thread feels correct to me. I like the consistency with isArray/getComponentType, even though the nulls feel old fashioned. The fast check of the direct super as jl.Record is a reasonable analogy to ACC_ENUM, although in hindsight maybe we should have just gated enum-ness on a direct

Re: Clarifying record reflective support

On 12/3/2019 6:24 AM, Chris Hegarty wrote: At least from the JVM side of things, one could lean on the JVMS, Section 4.1 “The ClassFile Structure”. While the draft records JVMS does amend various sections and subsections of Chapter 4, it does not touch section 4.1. Reading between the lines, I

Re: Clarifying record reflective support

Maurizio, > On 3 Dec 2019, at 12:18, Maurizio Cimadamore > wrote: > > Hi Chris, > I like your proposal; first, it makes isRecord/getRecordComponents in sync > with other similar pair of methods like isArray/getComponentType. Secondly, > it allows tighter tests to be written e.g. by the JCK

Re: Clarifying record reflective support

Hi Chris, I like your proposal; first, it makes isRecord/getRecordComponents in sync with other similar pair of methods like isArray/getComponentType. Secondly, it allows tighter tests to be written e.g. by the JCK team, which is, I think, where the value really is. In your updated sped we

Clarifying record reflective support

A number of issues and/or concerns have been come up recently relating to the reflective support for records. These arose when finalizing and completing the runtime CSR. Taken together they seem to lead back to a few small, but significant, omissions in the spec that would be good to tighten up.