Java 9模块系统严格限制匿名包访问，因其不属任何模块且不可导出或requires；迁移时需将所有匿名包类移至命名包并更新module-info.java，否则编译报“找不到符号”、运行抛NoClassDefFoundError或InaccessibleObjectException。

Java 9 引入模块系统后，匿名包（即未声明 package 的类所在的默认包）在模块路径下会被 JVM 严格限制访问——模块默认不导出匿名包，且其他模块无法读取或反射访问其中的类和变量。因此，将传统类路径（classpath）项目迁移到模块路径（module path）时，若存在匿名包中的 public 类或字段，会出现“找不到符号”“非法访问”或运行时 NoClassDefFoundError 等问题。

根本原因：模块系统对匿名包的隔离策略

Java 规范明确要求：模块只能导出命名包（named package），匿名包不属于任何模块，也不能被 requires 或 exports 声明。即使一个 JAR 放在模块路径上，其中的匿名包类也不会被自动解析为模块内可访问的类型。

• 编译期：javac 拒绝跨模块引用匿名包中的类（即使 public）
• 运行期：ModuleLayer 不加载匿名包类到任何命名模块中，Class.forName() 可能失败，反射访问字段/方法抛 InaccessibleObjectException
• JPMS 工具链（如 jdeps）会警告 “contains classes in the unnamed module”

解决方案：彻底消除匿名包

最直接、符合 JPMS 设计原则的做法是将所有匿名包内容迁移至显式命名包。这不是权宜之计，而是必要重构。

• 为每个无包的 .java 文件顶部添加合法 package 声明（如 package example.util;）
• 同步更新所有对该类的 import 引用（包括测试类、配置类、脚本中硬编码的类名）
• 若该类被其他模块依赖，目标模块的 module-info.java 中需添加 exports 对应包，并在依赖方添加 requires
• 注意资源路径变化：原 getClass().getResource("/config.txt") 需改为相对包路径或使用 ClassLoader.getSystemResource()

临时兼容方案（仅限过渡期）

若短期无法重构全部匿名包代码（如第三方遗留 JAR），可通过启动参数绕过部分限制，但不推荐用于生产环境：

• 添加 --add-opens java.base/java.lang=ALL-UNNAMED 允许反射访问（仅针对特定包+模块组合）
• 使用 --add-modules ALL-SYSTEM 强制加载系统模块（对匿名包本身无效，但可缓解间接依赖问题）
• 将含匿名包的 JAR 显式放回类路径：--class-path legacy.jar --module-path mods/，让 JVM 以传统方式加载它（此时它属于 unnamed module，其他模块仍不可见其内容，但自身可运行）

验证与工具辅助

迁移后务必验证匿名包是否清零：

• 运行 jdeps --module-path mods/ --recursive your-module，检查输出中是否还有 unnamed module 提示
• 用 javap -v YourClass.class | grep "SourceFile\|Constant pool" 确认 class 文件已归属命名包
• 在 module-info.java 中尝试 requires 旧类名会编译失败——这是正常现象，说明迁移生效