RFR: 8345565: Remove remaining SecurityManager motivated APIs from sun.reflect.util [v2]

Chen Liang liach at openjdk.org
Thu Dec 5 14:54:40 UTC 2024


On Thu, 5 Dec 2024 14:46:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> We hollowed out ReflectUtil as one of the early steps when removing the code for running in the SecurityManager execution mode. Most of the usages have now been removed so the empty (and unused) methods can be removed. FieldUtils and ConstructorUtils can be removed too.
>> 
>> ObjectInputStream/ObjectOutputStream has a left over package access check for the subclassing case that can be removed.
>> 
>> sun.reflect.generics.reflectiveObjects.TypeVariableImpl.getGenericDeclaration has a left over package access check that can be removed. I've changed the "should not happen" case to be an assert for now but it's in the wrong place. If we have a JDK bug in this area then it should be caught at construction time, not by the accessor method. This PR is focused on removing the use of ReflectUtil so don't want to do any more here.
>> 
>> The changes for java.management missed a usage ConstructorUtil.getConstructor in MBeanInstantiator.findConstructor. This is replaced, to allow ConstructorUtils be removed.
>> 
>> Testing: tier1-5
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright header end dates

Marked as reviewed by liach (Reviewer).

src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java line 138:

> 136:         assert genericDeclaration instanceof Class<?> ||
> 137:                 genericDeclaration instanceof Method ||
> 138:                 genericDeclaration instanceof Constructor : "Unexpected kind of GenericDeclaration";

Can remove this; check is already done in `make` factory.

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

PR Review: https://git.openjdk.org/jdk/pull/22572#pullrequestreview-2481936564
PR Review Comment: https://git.openjdk.org/jdk/pull/22572#discussion_r1871523443


More information about the serviceability-dev mailing list