JDK17 与 ButterKinife 冲突问题: class butterknife.compiler.ButterKnifeProcessor$RScanner

开发环境:

Android Studio Giraffe | 2022.3.1 Patch 1

Gradle插件:classpath 'com.android.tools.build:gradle:7.2.0'

Gradle版本:distributionUrl=https\://services.gradle.org/distributions/gradle-7.5-bin.zip

    Android Studio 升级到最新版后,带来一系列的更新(JDK、Gradle等),导致项目 Build 过程中错误频频,好不容易看到 Build Success 成功的字样,连接上真机设备安装过程中又报错了:

Cause: superclass access check failed: class butterknife.compiler.ButterKnifeProcessor$RScanner (in unnamed module @0x274412b0) cannot access class com.sun.tools.javac.tree.TreeScanner (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.tree to unnamed module @0x274412b0

    网上搜索了下,应该是 jdk17 与 ButterKnife 不兼容导致的,解决的办法如下:

方法一:降低JDK的版本

    在 Android Studio 的 setting - Build,Execution,Deployment - Build Tools - Gradle 可以选择下载 jdk 11 或 jdk 15, 下载成功后,重新 Build 项目即可。

如果在 Android studio 下载失败,可以自己手动到官网去下载安装,然后指定安装目录即可:

Android Studio -> File -> Project Structure -> SDK Location -> Click on Gradle Settings (blue hightlighted text) -> Select the jdk 11 with 11.0 something version name from list

方法二:编辑项目的 gradle.properties 文件

org.gradle.jvmargs=-Xmx1920M \
--add-exports=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED \
--add-exports=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED \
--add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED

    这是在 stackoverflow 搜索找到的解决方案,解释如下:

Some of the sun libraries needs to be made visible for the newer Java compilers. See this answer for more info. I added the following to our gradle.properties file and it fixed the problem. (We use Butterknife and Realm, and needed the below three packages added. (You might get away without "javac.code" for just Butterknife))

参考:How can I fix this error with ButterKnife in Android Studio? - Stack Overflow

  • 4
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
### 回答1: 这是一个Java程序运行时的异常,意味着在程序运行时尝试将一个类强制转换成另一个类型,但是转换失败了。具体错误信息提示是尝试将jdk.internal.loader.classloaders$appclassloader类转换为java.net.urlclassloader类,但是这两个类在Java平台的不同模块中。 ### 回答2: 该异常信息出现的原因是Java虚拟机在运行时无法将jdk.internal.loader.classloaders$appclassloader类型的对象转化为java.net.urlclassloader类型的对象。具体而言,可能是在使用反射机制时,将一个appClassLoader对象强制转化为了urlClassLoader对象,而这两个对象的实现方式、类层次结构等存在较大差异,导致无法进行转化的错误。 解决该异常问题的方法取决于具体的实现场景和程序结构,但通常可以从以下方面进行考虑: 1.确认使用反射的代码逻辑是否正确合理,是否真正需要对不同的ClassLoader对象进行转化。 2.检查程序中是否存在ClassLoader对象未正确初始化、引用空指针等常见错误。 3.在不影响核心逻辑的前提下,可以使用不同的ClassLoader实现方式进行调试,或者对相关的ClassLoader类进行深入了解和熟悉,从而掌握其适用场景和特点,尽可能避免调用不适合的方法和属性,减少出现ClassCastException等异常的概率。 总之,避免出现异常情况不仅需要程序员对相关异常的了解和熟悉,更需要将其视为代码质量和健康性的重要指标,从编码质量、测试覆盖等多个维度进行全面考虑和优化,从而运行出高效、安全、稳定、可维护的程序系统。 ### 回答3: 这个错误信息告诉我们,在Java程序中尝试将一个类加载器对象强制转换成另一个类加载器对象时失败了。具体来说,程序试图将一个名为`jdk.internal.loader.classloaders$appclassloader`的类加载器对象强制转换成`java.net.urlclassloader`类加载器对象,但由于这两个类加载器并没有继承关系,所以转换失败了。 这个错误通常是由于代码中存在类加载器的混淆或误用引起的。在Java中,每个类都有一个对应的类加载器,它负责将该类的字节码文件加载到内存中,并执行该类的代码。不同的类加载器可能负责加载不同的类,而且它们之间也有一定的父子关系。通常情况下,只有在确实需要使用多个类加载器的复杂场景下,才会涉及到类加载器的操作。如果程序没有正确使用类加载器,就容易出现这种类转换异常。 为了解决这个问题,可以检查代码中对类加载器的使用是否有误。可能需要重新设计程序结构,显式地指定正确的类加载器对象,或者避免直接使用类加载器而改用其他方式加载类。此外,也可以查阅Java类加载器相关的文档和资料,深入了解Java类加载器的细节和使用方法,以避免这类错误的发生。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

思涛的博客

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值