ClassPath.getTopLevelClasses()是否应返回java.*包下的类？

这绝对不是你的使用方式问题，也算不上Guava的Bug——核心原因是Java 9及以后引入的**模块系统（JPMS）**彻底改变了类的加载和封装规则，Guava的ClassPath工具还没完全适配这种新机制。

具体原因拆解 #

• 核心模块的封装特性：Java 9+把java.*这类核心包都放进了系统模块（比如java.base）里，默认情况下这些模块的内部包是被封装的，普通应用类加载器无法直接扫描到这些模块内的类。只有模块明确导出的包，且你的应用模块声明了依赖时，才能访问到对应的类，而Guava的ClassPath工具还是基于传统的类路径扫描逻辑，没法突破这种模块封装限制。
• Guava的适配局限性：虽然Guava 24.1和25.0已经开始适配Java 9+，但ClassPath工具的设计初衷是扫描**类路径（classpath）下的JAR和目录，对于模块路径（modulepath）**里的系统模块，它没有专门的逻辑去读取模块元数据来获取类列表，所以只能扫到部分非系统模块的类。

可行的解决方案 #

1. 改用Java模块API扫描系统类 #

如果确实需要获取java.*包下的类，可以直接使用Java自身提供的模块API来实现，示例代码如下：

import java.lang.module.Module;
import java.lang.module.ModuleDescriptor;
import java.util.Set;

public class SystemClassScanner {
    public static void main(String[] args) {
        // 获取启动层的所有系统模块
        Set<Module> bootModules = ModuleLayer.boot().modules();
        
        for (Module module : bootModules) {
            ModuleDescriptor desc = module.getDescriptor();
            System.out.println("=== 模块: " + desc.name() + " ===");
            
            // 遍历模块导出的所有包
            desc.exports().forEach(exp -> {
                String pkg = exp.source();
                System.out.println("导出包: " + pkg);
                // 可进一步通过模块资源流查找包下的类文件
                // 例如将包名转为路径: pkg.replace('.', '/') + "/"
            });
        }
    }
}

不过要注意，即使通过这种方式，模块未导出的内部类还是无法访问，这是模块系统的安全设计，无法绕过。

2. 临时兼容方案（不推荐长期使用） #

如果你的应用不需要模块化，可以在启动Java程序时添加参数，放宽模块封装限制：

java --illegal-access=permit -jar your-app.jar

但这个参数在Java 16及以后被彻底移除了，只能作为短期过渡方案。

内容的提问来源于stack exchange，提问作者rainbowgoblin