当前位置:Gxlcms > 数据库问题 > Java的非法反射警告illegal reflective access operation

Java的非法反射警告illegal reflective access operation

时间:2021-07-01 10:21:17 帮助过:17人阅读

反射是一项相当强大的特性,不仅在各类框架中被广泛应用,即使是在日常开发中我们也隔三差五得要和它打交道。然而在JDK9中JDK对反射加上了一些限制,需要注意。

考虑有如下的代码:

import java.lang.reflect.Field;
import java.util.ArrayList;

public class TestReflect {
    public static int getCapacity(ArrayList<?> l) throws Exception {
        Field dataField = l.getClass().getDeclaredField("elementData");
        dataField.setAccessible(true); // 即使设置了可访问也会触发警告
        return ((Object[]) dataField.get(l)).length; // 注意这行
    }

    public static void main(String[] args) {
        var arr = new ArrayList<Integer>(4);
        try {
            System.out.println("capacity:" + TestReflect.getCapacity(arr));        
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

这段代码的作用是读取ArrayList的实际容量,由于JDK并没有为我们提供类似cap()这样的公开接口,所以我们不得不使用反射来绕过限制。

在JDK8上这段代码运行良好,然而当我们升级成JDK9后却会是这样的一幅画面:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by TestReflect (file:/tmp/TestReflect.java) to field java.util.ArrayList.elementData
WARNING: Please consider reporting this to the maintainers of TestReflect
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
capacity:4

别紧张,代码还是正常运行了。其实这是JDK9中添加的新特性,即reflect不再可以访问non-public成员以及不可公开访问的class,原先这些访问控制虽然存在但是可以通过reflect绕过,从JDK9开始反射也将遵循访问控制的规则。JDK9中对于第一次访问非公开成员的操作会显示警告信息,我们可以通过``选项进一步显示出有用的warning提示:

$ java --illegal-access=warn TestReflect.java

WARNING: Illegal reflective access by TestReflect (file:/tmp/TestReflect.java) to field java.util.ArrayList.elementData
capacity:4

将warn替换为debug可以指出非法访问发生在哪一行(通过观察打印的调用堆栈),而替换为deny则将会直接抛出java.lang.reflect.InaccessibleObjectException异常:

$ java --illegal-access=deny TestReflect.java

java.lang.reflect.InaccessibleObjectException: Unable to make field transient java.lang.Object[] java.util.ArrayList.elementData accessible: module java.base does not "opens java.util" to unnamed module @72967906
        at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:349)
        at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:289)
        at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:174)
        at java.base/java.lang.reflect.Field.setAccessible(Field.java:168)
        at TestReflect.getCapacity(TestReflect.java:7)
        at TestReflect.main(TestReflect.java:14)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:564)
        at jdk.compiler/com.sun.tools.javac.launcher.Main.execute(Main.java:415)
        at jdk.compiler/com.sun.tools.javac.launcher.Main.run(Main.java:192)
        at jdk.compiler/com.sun.tools.javac.launcher.Main.main(Main.java:132)

对于后续的更新版本,JDK会将deny作为默认的行为,不过目前(14.0.2)默认行为依旧为permit(显示那些默认的warning信息)。

显而易见,新特性会导致如下的结果:

  1. 无法再通过反射修改/访问其他类型的私有成员;
  2. 无法再通过反射使用internal APIs

然而健康的代码并不应该依赖于非法的访问:

  1. 标记为非公开的成员本身就不希望被外部直接访问,访问应该通过public APIs进行;
  2. 无视访问控制会导致数据的修改变得不可控,从而产生意想不到的缺陷;
  3. 私有成员可能会随着开发/更新/修复/重构等活动而改变,过度依赖于访问其他class的私有成员会产生高耦合性的代码,使维护的负担成倍增加

当然,想要消除警告也很容易,虽然官方文档中不建议无视或消除这个警告:

$ java --add-opens java.base/java.util=ALL-UNNAMED TestReflect.java

capacity:4

--add-opens选项将特定的module下的package公开给制定的package,或者使用特殊值ALL-UNAMED代指所有匿名包(比如本例中的类),公开后我们就可以通过reflect来访问被公开包中class的成员而不抛出异常了(需要使用setAccessible(true)

这种trick实际上严重破坏了代码的封装,个人是极不推荐的;此外还可以选择将JDK版本锁定在8,当然这也是不得以才为之的办法,那么对于即想尝试新版本又不想被警告信息烦扰的话该怎么办呢,只能尝试下面几种办法了:

  1. 如果是第三方依赖导致的警告,升级对应的依赖或是联系该依赖的维护人员,请他们尽快修复问题。通常来说这类向后兼容的问题修复无需花费很多的时间。
  2. 如果是自己的代码,则考虑是否要对私有成员提供可访问的public API,是否将私有成员公有化。
  3. 如果使用了某些internal apis,那么你的代码应该重构以避免过度依赖这些api。
参考资料

https://blog.codefx.org/java/java-9-migration-guide/#Illegal-Access-To-Internal-APIs
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-June/012841.html

Java的非法反射警告illegal reflective access operation

标签:perm   array   report   匿名   tin   open   锁定   ext   怎么   

人气教程排行