KSP项目中Guava依赖冲突导致的IllegalAccessError问题分析

问题背景

在Kotlin Symbol Processing (KSP)项目中使用Dagger时，开发者可能会遇到一个IllegalAccessError异常。这个错误通常发生在同时使用Kotlin 2.0.0、KSP 2.0.0-1.0.22（启用了ksp.useKSP2=true）和Dagger 2.51.1的环境中。

错误表现

错误堆栈显示如下关键信息：

java.lang.IllegalAccessError: failed to access class com.google.common.base.NullnessCasts from class com.google.common.base.Suppliers$NonSerializableMemoizingSupplier

这个错误表明在运行时发生了类访问权限问题，具体是Suppliers$NonSerializableMemoizingSupplier类试图访问NullnessCasts类时失败。

根本原因

经过深入分析，这个问题源于Guava库的版本冲突。具体来说：

1. KSP内部使用了shaded（重命名包路径）的Guava库
2. Dagger也依赖了Guava库，但使用的是原始包路径
3. 当多个KSP任务在同一个Gradle项目中运行时，每个任务使用独立的类加载器
4. 第一个任务加载了原始Guava的NullnessCasts类
5. 第二个任务尝试通过shaded版本的Guava访问这个类时，由于包可见性限制而失败

技术细节

类加载隔离问题在Java/Kotlin构建系统中并不罕见。在这个特定案例中：

• KSP任务使用自定义类加载器来隔离处理环境
• 由于JVM的类加载机制，一旦类被加载，即使来自不同类加载器，也无法重新加载
• Guava内部的一些类（如NullnessCasts）具有包级可见性
• 当不同版本的Guava类被混合使用时，就会违反Java的访问控制规则

解决方案

KSP团队已经意识到这个问题，并在1.0.24版本中进行了修复：

1. 将KSP的artifact从symbol-processing-aa改为symbol-processing-aa-embeddable
2. 新的artifact会对所有bundled依赖进行重命名，彻底避免潜在的冲突

对于开发者来说，解决方案很简单：升级到KSP 1.0.24或更高版本即可解决这个问题。

经验教训

这个案例展示了依赖管理在构建系统中的重要性，特别是：

1. 库开发者应该考虑shading关键依赖，避免污染用户类路径
2. 构建工具需要妥善处理类加载隔离问题
3. 当使用多个代码生成工具时，要特别注意它们的依赖兼容性

对于Android开发者来说，这类问题在multidex或动态特性模块场景下尤为常见，理解类加载机制有助于更快地诊断和解决问题。