Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17]

2022-06-13 Thread Joe Darcy
On Wed, 13 Apr 2022 21:21:25 GMT, liach wrote: >> src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 167: >> >>> 165: * but is optional in the dynamic phase, during execution. >>> 166: */ >>> 167: STATIC(AccessFlag.STATIC.mask()), >>

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17]

2022-05-03 Thread Joe Darcy
On Fri, 29 Apr 2022 20:34:21 GMT, Mandy Chung wrote: > I took a closer look at the proposed APIs. I think it's in a good state to > target for 19. I skimmed on the existing JDK usage of `getModifiers` other > than a trivial test e.g. is public, final, etc and the proposed API works > well

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17]

2022-04-29 Thread Mandy Chung
On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is >> "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but >>

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17]

2022-04-13 Thread liach
On Wed, 13 Apr 2022 21:12:40 GMT, ExE Boss wrote: >> Joe Darcy has updated the pull request with a new target base due to a merge >> or a rebase. The incremental webrev excludes the unrelated changes brought >> in by the merge/rebase. The pull request contains 26 additional commits >> since

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17]

2022-04-13 Thread ExE Boss
On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is >> "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but >>

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17]

2022-04-13 Thread liach
On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is >> "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but >>

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17]

2022-04-07 Thread Joe Darcy
On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is >> "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but >>

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17]

2022-03-10 Thread Joe Darcy
On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is >> "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but >>

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17]

2022-03-09 Thread Peter Levart
On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is >> "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but >>

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17]

2022-03-09 Thread Peter Levart
On Tue, 8 Mar 2022 00:19:58 GMT, Joe Darcy wrote: > > The mapping from Location to AccessFlag(s) could be implemented event > > without using a Map. You just have to be careful not to use EnumSet for > > that (i.e. before AccessFlag enum constants are fully initialized) - an > > ArrayList is

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17]

2022-03-07 Thread Joe Darcy
On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is >> "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but >>

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17]

2022-03-07 Thread Joe Darcy
On Mon, 7 Mar 2022 18:20:23 GMT, Roger Riggs wrote: >> Joe Darcy has updated the pull request with a new target base due to a merge >> or a rebase. The incremental webrev excludes the unrelated changes brought >> in by the merge/rebase. The pull request contains 26 additional commits >> since

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17]

2022-03-07 Thread Roger Riggs
On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is >> "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but >>

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17]

2022-03-07 Thread Peter Levart
On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is >> "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but >>

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17]

2022-03-07 Thread Peter Levart
On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is >> "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but >>

Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17]

2022-03-05 Thread Joe Darcy
> This is an early review of changes to better model JVM access flags, that is > "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but > distinct. There are concepts that overlap in the two domains