Java Module Import Declaration 会改变哪些导入规则

Java 25 的 Module Import Declaration 新增了 import module M;。它会把模块 M 对当前模块可见的已导出包，以及通过 requires transitive 可读模块的已导出包，统一按需导入。最终进入简单名解析范围的是这些包里的 public 顶层类和接口，不是模块里的所有类型，也不是静态成员。

这项变化最适合原型、教学、JShell 和需要同时使用一个模块多个包的短程序。原有的 import java.util.*;、单类型导入和静态导入仍然有效；出现同名类型时，更具体的导入还能覆盖模块导入带来的候选。JEP 511 已在 JDK 25 交付，不再需要预览参数。

一行模块导入，替代的是一组已导出包

传统星号导入面向一个包，例如 import java.util.*;。模块导入面向一个具名模块，例如：

import module java.base; // 按需导入 java.base 已导出包中的 public 顶层类型

class ImportDemo {
    public static void main(String[] args) {
        // List 来自 java.util，Path 来自 java.nio.file
        List paths = List.of(Path.of("README.md"));
        System.out.println(paths.getFirst().getFileName());
    }
}

这里没有分别写 java.util.List、java.nio.file.Path，因为两个包都由 java.base 导出。可以把它理解为编译器根据模块描述推导出一组包级按需导入，但不要把它理解成“递归扫描模块内所有实现类”。

用 JDK 25 建立一个最小可编译示例

这个小程序只需要一个源文件，不要求先创建 module-info.java。保存上面的代码为 ImportDemo.java，然后使用 JDK 25 编译：

# 用 Java 25 的正式语言规则编译，不需要 --enable-preview
javac --release 25 ImportDemo.java

# 运行生成的类，核对 Path 与 List 都已正确解析
java ImportDemo

示例预期打印文件名：

README.md

如果编译器在 import module 处报告语法错误，先核对 javac -version 是否为 25 或更高版本。若只看到运行时版本，而实际调用的是旧版 javac，仍然无法识别新语法。

真正改变的是三层可见性规则

判断某个简单类型名能否使用时，可以按下面三层边界检查：

例如模块 M1 有 requires transitive M4，那么 import module M1; 可以同时纳入 M1 和 M4 对当前模块可见的导出包。若 M1 只是 requires M5，则不能据此把 M5 的导出包一并导入。

还有一个容易误解的边界：import module 接受的是模块名，因此不能用它导入未命名模块，也不能用它替代类路径上的包级导入。它改变的是源文件中的类型简单名解析，不会替你修改运行时依赖，也不会自动生成 requires。

发生同名冲突时，用更具体的 import 收口

模块导入一次带入多个包，同名类型变多是最现实的代价。例如 java.util.List 与 java.awt.List 都叫 List，java.util.Date 与 java.sql.Date 都叫 Date。只有代码真正使用这个简单名时，编译器才会报告歧义。

import module java.base;    // 带来 java.util.List 和 java.util.Date 等候选
import module java.desktop; // 带来 java.awt.List 和多个 Element 候选

import java.util.*;         // 包级按需导入比 module import 更具体，List 解析到 java.util.List
import java.sql.Date;       // 单类型导入最具体，Date 明确解析到 java.sql.Date

class ImportPriorityDemo {
    List names = List.of("Ada", "Linus"); // 明确使用 java.util.List
    Date createdAt;                               // 明确使用 java.sql.Date
}

优先级可以记成：单类型导入 > 包级按需导入 > 模块导入。单类型导入能遮蔽后两者；包级按需导入能遮蔽模块导入，但不能遮蔽已经存在的单类型导入。如果两个模块都贡献了同名类型，而你没有补更具体的导入，简单名就保持歧义。

类路径代码能用，但模块可读性仍然存在

import module 可以写在显式模块中的源文件，也可以写在普通类路径源文件中，所以使用它不等于必须先把自己的应用模块化。常见的 java.base、java.sql 等平台模块可以直接用于普通源文件。

不过，模块解析规则没有消失。聚合模块 java.se 会传递聚合标准 Java API，但在未命名模块的默认根模块集合中并不一定被解析。JEP 511 明确说明：普通类路径源文件直接写 import module java.se; 可能失败；在显式模块中，通常需要先在 module-info.java 里 requires java.se;。

module demo.app {
    requires java.se; // 先建立对聚合模块的读取关系
}

另外，JDK 25 的 compact source file 会隐式获得类似 import module java.base; 的效果。普通显式类文件没有这项自动模块导入，仍需自己写声明。迁移代码时要区分这两种源文件形态。

什么时候值得采用，怎么验收

模块导入的目标是降低原型和探索阶段的导入噪声，并不意味着成熟项目必须把所有单类型导入都改掉。可以按以下标准判断：

• 适合：短程序、教学样例、JShell 探索、刚接触一个模块且会同时使用多个导出包。
• 谨慎：大型长期维护代码、经常出现同名类型的桌面或企业项目、团队明确要求单类型导入的代码库。
• 不适用：想访问未导出包、非 public 类型、类路径中的未命名模块，或希望它替代 requires 的场景。

提交前做一次简短验收：确认构建使用 JDK 25 或更高版本；确认目标包确实由模块导出；检查 IDE 是否提示简单名歧义；对关键业务类型补单类型导入；最后再看导入缩短后是否仍能让维护者一眼知道核心依赖来自哪里。

相关问题

import module 会导入子包吗？

它不是按包名递归导入子包，而是根据模块描述一次纳入多个已导出包。某个子包只有在模块实际导出时才会进入范围。

它和 module-info.java 里的 requires 一样吗？

不一样。requires 建立模块读取关系；import module 在源文件里把可读模块的已导出包纳入简单名解析。两者解决的问题不同。

模块导入会自动导入静态方法吗？

不会。静态成员仍然使用 import static，例如 import static java.util.stream.Collectors.toList;。

为什么 import module java.se 在普通类路径程序里可能失败？

因为 java.se 不属于未命名模块默认解析的根模块集合。显式模块可以通过 requires java.se; 建立读取关系，再在源文件中使用模块导入。