From liangchenblue at gmail.com Sat Nov 4 01:23:04 2023 From: liangchenblue at gmail.com (-) Date: Sat, 4 Nov 2023 09:23:04 +0800 Subject: Signature.TypeArg to change to algebraic type Message-ID: Hello, I am currently looking into reimplementing core reflection's signature parsing to be based off the new Class-file API. One thing I noticed when using Signature.TypeArg is that it is a perfect candidate for algebraic data type, like: TypeArg - Unbounded: a singleton ENUM - Bounded: has 2 fields: 3-way wildcard indicator (+-and none), a RefTypeSig Alternatively, Bounded can be split into 3 classes that each hold a RefTypeSig instead of using the 3-way indicator, for the ref type sig is not really interchangeable. This model's main advantage is that users can be assured that they can just obtain RefTypeSig if the TypeArg is bounded, without having to write dubious Optional.get()/orElseThrow() in user code. Best, Chen Liang -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Sat Nov 4 14:06:12 2023 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 4 Nov 2023 10:06:12 -0400 Subject: Signature.TypeArg to change to algebraic type In-Reply-To: References: Message-ID: <3c658fbe-5b5b-3d9b-2cec-33ad8894aa67@oracle.com> Makes sense.? Would be good to rough this out to see the impact on the codebase? On 11/3/2023 9:23 PM, - wrote: > Hello, > I am currently looking into reimplementing core reflection's signature > parsing to be based off the?new Class-file API. > > One thing I noticed when using Signature.TypeArg is that it is a > perfect candidate for algebraic data type, like: > TypeArg > ? - Unbounded: a singleton ENUM > ? - Bounded: has 2 fields: 3-way wildcard indicator (+-and none), a > RefTypeSig > > Alternatively, Bounded can be split into 3 classes that each hold a > RefTypeSig instead of using the 3-way indicator, for the ref type sig > is not really interchangeable. > > This model's main advantage is that?users can be assured that they can > just obtain RefTypeSig if the TypeArg is bounded, without having to > write dubious Optional.get()/orElseThrow() in user code. > > Best, > Chen Liang -------------- next part -------------- An HTML attachment was scrubbed... URL: From liangchenblue at gmail.com Sat Nov 4 15:07:32 2023 From: liangchenblue at gmail.com (-) Date: Sat, 4 Nov 2023 23:07:32 +0800 Subject: Signature.TypeArg to change to algebraic type In-Reply-To: <3c658fbe-5b5b-3d9b-2cec-33ad8894aa67@oracle.com> References: <3c658fbe-5b5b-3d9b-2cec-33ad8894aa67@oracle.com> Message-ID: Currently, TypeArg is only used by 2 consumers: javap and Class-File API's own Class remapper. This impact should be relatively miniscule. The creation factories will be updated to return the more specific types; too. Currently, no producer in the JDK uses those factories except Class-File API's own parsing. Thus, I believe the impact is on the lesser end. Before we perform the refactor, should we handle default, extends, super in one class + 3-value enum or 3 classes (like RuntimeInvisible/Visible annotations)? On Sat, Nov 4, 2023 at 10:06?PM Brian Goetz wrote: > Makes sense. Would be good to rough this out to see the impact on the > codebase? > > > > On 11/3/2023 9:23 PM, - wrote: > > Hello, > I am currently looking into reimplementing core reflection's signature > parsing to be based off the new Class-file API. > > One thing I noticed when using Signature.TypeArg is that it is a perfect > candidate for algebraic data type, like: > TypeArg > - Unbounded: a singleton ENUM > - Bounded: has 2 fields: 3-way wildcard indicator (+-and none), a > RefTypeSig > > Alternatively, Bounded can be split into 3 classes that each hold a > RefTypeSig instead of using the 3-way indicator, for the ref type sig is > not really interchangeable. > > This model's main advantage is that users can be assured that they can > just obtain RefTypeSig if the TypeArg is bounded, without having to write > dubious Optional.get()/orElseThrow() in user code. > > Best, > Chen Liang > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Sat Nov 4 22:35:31 2023 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 4 Nov 2023 18:35:31 -0400 Subject: Signature.TypeArg to change to algebraic type In-Reply-To: References: <3c658fbe-5b5b-3d9b-2cec-33ad8894aa67@oracle.com> Message-ID: <9653eb43-b177-37e4-3a5d-c89c9da6df3e@oracle.com> > Thus, I believe the impact is on the lesser end. Before we perform the > refactor, should we handle default, extends, super in one class?+ > 3-value enum or 3 classes (like RuntimeInvisible/Visible annotations)? I think the enum approach is probably better suited to this situations.? We have separate R{VI}AA classes because we decided "every attribute defined in the JVMS should have its own attribute subtype" (and similar with each kind of classfile metadata), but for something as simple as this an enum for variance seems more properly sized. From liangchenblue at gmail.com Mon Nov 6 07:45:17 2023 From: liangchenblue at gmail.com (-) Date: Mon, 6 Nov 2023 15:45:17 +0800 Subject: Signature.TypeArg to change to algebraic type In-Reply-To: <9653eb43-b177-37e4-3a5d-c89c9da6df3e@oracle.com> References: <3c658fbe-5b5b-3d9b-2cec-33ad8894aa67@oracle.com> <9653eb43-b177-37e4-3a5d-c89c9da6df3e@oracle.com> Message-ID: Thanks for your suggestions, Brian. I have created a patch at https://github.com/openjdk/jdk/pull/16517 for preliminary reviews. The 2 usage updates in remapper and javap are good examples of how the new user code will look like. One minor detail I wish to discuss: should we rename WildcardIndicator.DEFAULT to NONE? To be closer to the representation in JVMS. Another remark: I initially wanted to additionally expose signatureString() for TypeArg, but after more thinking, I believe the merit of ClassSignature, MethodSignature, and Signature having signatureString() is due to them being directly usable within Signature attributes. In contrast, there's no case in which a TypeArg is used alone. And the single signatureString() method usage in the implementation was updated in favor of a switch. On Sun, Nov 5, 2023 at 6:35?AM Brian Goetz wrote: > > > > Thus, I believe the impact is on the lesser end. Before we perform the > > refactor, should we handle default, extends, super in one class + > > 3-value enum or 3 classes (like RuntimeInvisible/Visible annotations)? > > I think the enum approach is probably better suited to this situations. > We have separate R{VI}AA classes because we decided "every attribute > defined in the JVMS should have its own attribute subtype" (and similar > with each kind of classfile metadata), but for something as simple as > this an enum for variance seems more properly sized. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liangchenblue at gmail.com Fri Nov 17 23:24:18 2023 From: liangchenblue at gmail.com (-) Date: Sat, 18 Nov 2023 07:24:18 +0800 Subject: API tweaks for JEP 457 Message-ID: Hello, I believe that there are some issues with the current API of Class-File API, where the class signature should require its superclass and superinterfaces to be class types (https://github.com/openjdk/jdk/pull/16514) and the type argument model adjustment ( https://github.com/openjdk/jdk/pull/16517). Yet, the current Class-File API JEP is finalized and targeting JDK 22. Should these 2 improvements make their way into the JEP, or should they become separate patches integrated after the JEP's integration? Making them part of the JEP may increase effort to integration, and making them separate will require CSR filling and probably will cause these fixes to fail to catch up with JDK 22. Best, Chen Liang -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Sat Nov 18 00:34:07 2023 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 17 Nov 2023 19:34:07 -0500 Subject: API tweaks for JEP 457 In-Reply-To: References: Message-ID: <990b611d-809b-4e60-9592-937fe3c124ee@oracle.com> Slight correction; the JEP is attempting to get to Preview in 22.? There will be still time to make API adjustments. On 11/17/2023 6:24 PM, - wrote: > Hello, > I believe that there are some issues with the current API of > Class-File API, where the class signature should require its > superclass and superinterfaces to be class types > (https://github.com/openjdk/jdk/pull/16514) and the type > argument?model adjustment (https://github.com/openjdk/jdk/pull/16517). > Yet, the current Class-File API JEP is finalized and targeting JDK 22. > > Should these 2 improvements?make their way into the JEP, or should > they become separate patches integrated after the JEP's integration? > Making?them part of the JEP may increase effort to integration, and > making them separate will require CSR filling and probably will cause > these fixes to fail to catch up with JDK 22. > > Best, > Chen Liang -------------- next part -------------- An HTML attachment was scrubbed... URL: