On Tue, 14 Jun 2022 02:32:54 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
>> dis
On Tue, 14 Jun 2022 02:32:54 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
>> dis
> 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
On Wed, 1 Jun 2022 05:09:42 GMT, ExE Boss wrote:
>> Or `AbstractMethodError`, which is what `Executable::getParameterCount()`
>> does:
>> https://github.com/openjdk/jdk/blob/e751b7b1b6f7269a1fe20c07748c726536388f6d/src/java.base/share/classes/java/lang/reflect/Executable.java#L248-L258
>
> Actua
On Tue, 14 Jun 2022 01:40:53 GMT, liach wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Make mask fields final in ModuleDescriptor.
>
> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 300:
>
>> 298
On Tue, 31 May 2022 17:23:18 GMT, Rémi Forax wrote:
>> For completeness, I think including SUPER is reasonable, even though has
>> been a no-op for some time. (Some time in the future, there could be a class
>> file version aware additions to this enum class.) Well spotted omission.
>
> `ACC_SU
On Tue, 14 Jun 2022 01:25:02 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
>> dis
> 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
On Tue, 31 May 2022 17:20:08 GMT, Rémi Forax 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 32 additional commits
>> since
> 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
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()),
>>
>>
> 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
On Tue, 15 Feb 2022 09:06:02 GMT, ExE Boss wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Respond to more review feedback.
>
> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 163:
>
>> 161: *
On Wed, 25 May 2022 00:35:24 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
>> dis
On Wed, 25 May 2022 00:35:24 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
>> dis
On Wed, 1 Jun 2022 05:01:33 GMT, ExE Boss wrote:
>> src/java.base/share/classes/java/lang/reflect/Member.java line 96:
>>
>>> 94: */
>>> 95: public default Set accessFlags() {
>>> 96: return Set.of();
>>
>> Is is not better to throw a NoSuchMethodError instead of Set.of() if th
On Tue, 31 May 2022 17:26:35 GMT, Rémi Forax 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 32 additional commits
>> since
On Wed, 25 May 2022 00:35:24 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
>> dis
On Tue, 15 Feb 2022 21:05:08 GMT, Joe Darcy wrote:
>> Note that the presence or absence of `ACC_SUPER` has no effect since **Java
>> 8**, which always treats it as set regardless of the actual contents of the
>> binary class file.
>
> For completeness, I think including SUPER is reasonable, eve
On Wed, 25 May 2022 00:35:24 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
>> dis
On Wed, 25 May 2022 00:35:24 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
>> dis
On Fri, 27 May 2022 20:21:12 GMT, Mandy Chung wrote:
> With the `AccessFlag` API, what is the role of the `Modifier` API going
> forward? [Value Objects JEP](https://openjdk.java.net/jeps/8277163) defines
> the new `identity` and `value` modifiers. [PR
> #698](https://github.com/openjdk/valhal
On Fri, 27 May 2022 21:53:38 GMT, Roger Riggs wrote:
> As for retaining SUPER, both SUPER and IDENTITY have location class and
> according to the BasicAccessFlagTest, the bit patterns should be disjoint
If the defined set of class locations, considered over time, have non-disjoint
definiti
On Wed, 25 May 2022 00:35:24 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
>> dis
On Wed, 25 May 2022 00:35:24 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
>> dis
On Wed, 25 May 2022 00:35:24 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
>> dis
On Wed, 25 May 2022 00:35:24 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
>> dis
On Wed, 25 May 2022 00:35:24 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
>> dis
On Wed, 25 May 2022 19:22:51 GMT, Roger Riggs wrote:
> AccessFlags.SUPER can/should be removed; it is unused and will be redefined
> in the [Value Objects JEP](https://openjdk.java.net/jeps/8277163). It will be
> a cleaner transition if there is no opportunity to create a dependency on the
> o
On Wed, 25 May 2022 00:35:24 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
>> dis
On Tue, 3 May 2022 21:35:48 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
>> dist
> 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
On Tue, 3 May 2022 21:35:48 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
>> dist
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 (btw
> 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
> 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
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
>> dist
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 th
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
>> dist
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
>> dist
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
>> dist
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
>> dist
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
>> dist
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 b
On Mon, 7 Mar 2022 11:22:29 GMT, Peter Levart wrote:
>>> It does because of the AccessFlags.MODULE constant.
>>
>> But that’s exactly what the unqualified `MODULE` identifier refers to, and
>> there’s no other bare `MODULE` identifier in scope that would shadow the
>> `AccessFlag.MODULE` const
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
>> dist
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
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
>> dist
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
>> dist
On Mon, 28 Feb 2022 18:20:13 GMT, ExE Boss wrote:
>> It does because of the AccessFlags.MODULE constant.
>
>> It does because of the AccessFlags.MODULE constant.
>
> But that’s exactly what the unqualified `MODULE` identifier refers to, and
> there’s no other bare `MODULE` identifier in scope t
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
>> dist
> 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
On Tue, 1 Mar 2022 02:11:26 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
>> dist
> 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
On Thu, 24 Feb 2022 01:17:23 GMT, Joe Darcy wrote:
> It does because of the AccessFlags.MODULE constant.
But that’s exactly what the unqualified `MODULE` identifier refers to, and
there’s no other bare `MODULE` identifier in scope that would shadow the
`AccessFlag.MODULE` constant from the POV
On Mon, 14 Feb 2022 21:24:47 GMT, Mandy Chung wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Respond to review feedback explicitly stating returned sets are immutable.
>
> I'm glad to see this proposal moving along t
On Wed, 23 Feb 2022 17:05:58 GMT, ExE Boss wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Initial support for accessFlags methods
>
> src/java.base/share/classes/java/lang/Class.java line 1331:
>
>> 1329: //
> 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
On Wed, 23 Feb 2022 02:13:21 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
>> dis
> 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
> 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
On Wed, 23 Feb 2022 02:13:21 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
>> dis
> 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
On Wed, 23 Feb 2022 00:40: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
>> dis
> 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
> 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
On Fri, 18 Feb 2022 14:53:42 GMT, Roger Riggs wrote:
> The Location enum does give more control over the places modifiers can occur
> and be extended as needed. But its unfortunate there's no (simple/obvious)
> mapping to the other concepts of the corresponding types, such as ElementType
> or
On Fri, 18 Feb 2022 03:38:36 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
>> dis
> 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
On Thu, 17 Feb 2022 20:32:45 GMT, ExE Boss wrote:
> Note that the `accessFlags()` method is still missing in the
> `ModuleDescriptor.Opens` and the top‑level `ModuleDescriptor` classes:
>
> https://github.com/openjdk/jdk/blob/5cc6ba50b1155340d13bc29d581c91ac543d2d95/src/java.base/share/classes/
> 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
Okay; I'll work on a location/context enum to model where flags can
appear for the next iteration as the place-holder ElementType enum fro
annotations doesn't quite work for this VM-centric context.
Thanks,
-Joe
On 2/17/2022 10:16 AM, Brian Goetz wrote:
Yes, and ...
There are words of flags
On Thu, 17 Feb 2022 19:26:13 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
>> dis
> 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
On 2/17/2022 8:34 AM, Roger Riggs wrote:
On Thu, 17 Feb 2022 01:38:42 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 flag
On Wed, 16 Feb 2022 13:18:47 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 seven additional commits
>> since
Yes, and ...
There are words of flags elsewhere scattered through the JDK, such the
InnerClasses attribute, module flags in the Module attribute, and flags
on the "requires" entries in the Module attribute. Having one
abstraction to cover all these locations, even though reflection doesn't
c
On Thu, 17 Feb 2022 01:38:42 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
>> dis
> 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
On Tue, 15 Feb 2022 21:09:57 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
>> dis
On Tue, 15 Feb 2022 09:04:02 GMT, ExE Boss wrote:
>> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 55:
>>
>>> 53: */
>>> 54: @SuppressWarnings("doclint:reference") // cross-module link
>>> 55: public enum AccessFlag {
>>
>> I think there is missing SUPER ACC_SUPER 0x0020
On Tue, 15 Feb 2022 07:17:12 GMT, Adam Sotona wrote:
> I would also recommend to sort access flags by the mask value. Sorted flags
> will match the specification and it will also make more deterministic all
> operations crawling through all the flags. This AccessFlag enum is very
> useful even
> 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
On Mon, 14 Feb 2022 22:47:53 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
>> dis
On Tue, 15 Feb 2022 06:56:51 GMT, Adam Sotona wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Respond to more review feedback.
>
> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 55:
>
>> 53: */
>
On Mon, 14 Feb 2022 22:47:53 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
>> dis
On Mon, 14 Feb 2022 22:47:53 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
>> dis
> 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
On Mon, 14 Feb 2022 21:12:51 GMT, Mandy Chung wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Respond to review feedback explicitly stating returned sets are immutable.
>
> src/java.base/share/classes/java/lang/reflec
On Mon, 14 Feb 2022 22:07:24 GMT, Joe Darcy wrote:
>> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 146:
>>
>>> 144: */
>>> 145: SYNTHETIC(0x1000, false,
>>> 146: Set.of(TYPE, FIELD, METHOD, CONSTRUCTOR,
>>> ElementType.MODULE, PARAMETER)),
>>
>>
On Mon, 14 Feb 2022 21:10:22 GMT, Mandy Chung 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 three additional commits
>> si
On Mon, 14 Feb 2022 20:52:28 GMT, Joe Darcy wrote:
>> Thanks for catching the typo Adam; I'll fix it in the next push.
>
>> Looks promising, some comments:
>>
>> The terminology in the JVMS is about modifiers; can the class name include
>> the word Modifier, perhaps ModifierFlag(s)? Several of
On Mon, 14 Feb 2022 20:02:50 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
>> dis
On Mon, 14 Feb 2022 21:00:45 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
>> dis
On Mon, 14 Feb 2022 21:00:45 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
>> dis
> 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
On Mon, 14 Feb 2022 18:12:13 GMT, Joe Darcy wrote:
>> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 206:
>>
>>> 204: * modifier in the Java programming language}
>>> 205: */
>>> 206: public boolean sourceModifer() {
>>
>> probably a typo - should be sourceModi
> 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
On Mon, 14 Feb 2022 16:29:36 GMT, Adam Sotona 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
>> d
On Fri, 11 Feb 2022 18:31:57 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
> distinct
1 - 100 of 102 matches
Mail list logo
