RFR: 8261400: Reflection member filtering registration might be flawed
Alan Bateman
alanb at openjdk.org
Tue Jul 16 13:38:54 UTC 2024
On Fri, 5 Jul 2024 19:27:27 GMT, Chen Liang <liach at openjdk.org> wrote:
> Please review this patch that address the reflection member filtering flaws.
>
> 1. Remove a pointless bootstrap check to ensure no filter is accidentally bypassed due to class-loading order.
> 2. Clarify the scenarios for filtering, and the correct filter actions for each scenario.
> 3. Remove the filter in `sun.misc.Unsafe`; users are already using other ways to steal this instance, bypassing the filtered getter. The `jdk.internal.misc.Unsafe`'s filter was already removed in JDK-8161129, so this filter is meaningless.
src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 56:
> 54:
> 55: static {
> 56: // 3 filter scenarios:
Using "3" is a bit confusing here because the next line starts with "1.". So maybe change it to "Three" or drop completely as I don't think they are too helpful.
src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 58:
> 56: // 3 filter scenarios:
> 57: // 1. Classes loaded before Reflection, may (System) or may not
> 58: // (ConstantPool) be initialized before main call: below
This comment is confusing. I assume you want to say that these classes may or may not be loaded before the application main method. It may be simpler to just drop the proposed comments as they beg too many questions.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20058#discussion_r1679407923
PR Review Comment: https://git.openjdk.org/jdk/pull/20058#discussion_r1679412547
More information about the core-libs-dev
mailing list