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
>
>
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
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
>>
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
>>
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
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
>>
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
>>
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
>>
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
>
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
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
>>
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
>>
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
>>
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
>>
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
>>
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
>
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
>>
> 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
19 matches
Mail list logo
