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