On Wed, 10 Jun 2026 14:50:47 GMT, Alan Bateman <[email protected]> wrote:

>> Chen Liang has updated the pull request incrementally with two additional 
>> commits since the last revision:
>> 
>>  - Years
>>  - Formatting and add an example
>
> src/java.base/share/classes/java/lang/reflect/package-info.java line 27:
> 
>> 25: 
>> 26: /**
>> 27:  * Provides classes and interfaces, in addition to {@link Class 
>> java.lang.Class},
> 
> Maybe we should add "and java.lang.Module" to this.

I included java.lang.Class because on JBS, many of its changes belong to 
`java.lang:reflect` subcompnent like all `java.lang.reflect` changes. If we 
include `Module`, we can argue for inclusion of `Package` etc. I personally 
would prefer to drop "in addition to java.lang.Class" if this becomes confusing.

> src/java.base/share/classes/java/lang/reflect/package-info.java line 73:
> 
>> 71:  * to produce a {@link MethodHandle} that performs no additional access 
>> checks.
>> 72:  * If the accessed declaration is a member, the single check is performed
>> 73:  * against the correct class or interface of the member.  In the example 
>> above,
> 
> The new AC section starts with text to show that reflect APIs are caller 
> sensitive and there is access check at each call.  It feels like sentences on 
> when the access check is done with method handles should follow that. I think 
> that would flow better so that the issue can inherited methods isn't in the 
> middle of the section.

I am advertising MethodHandles as the preferred alternative to legacy 
reflective invocation instead of comparing the two; I am trying to emphasize 
the correct owner is being checked. I don't think your proposed refactor 
accomplishes the goal better, but some refactoring is definitely necessary 
because you failed to see this as an advertisement.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28685#discussion_r3389544036
PR Review Comment: https://git.openjdk.org/jdk/pull/28685#discussion_r3389531876

Reply via email to