当使用 Java 模块系统（JPMS）时，若公开方法返回 java.sql.Connection 等类型，但未声明 requires transitive java.sql，模块客户端将无法访问该类型，从而触发编译警告。
当使用 java 模块系统（jpms）时，若公开方法返回 `java.sql.connection` 等类型，但未声明 `requires transitive java.sql`，模块客户端将无法访问该类型，从而触发编译警告。
在基于 Java 9+ 的模块化项目（如使用 JDK 20 和 JavaFX）中，java.sql 是一个独立命名模块。当你在 public 方法中直接暴露 Connection、ResultSet 或 PreparedStatement 等来自 java.sql 模块的类型时，调用方模块必须能“看到”并访问这些类型——这不仅要求你的模块 requires java.sql，还要求它 以传递方式（transitively）导出该依赖，否则其他模块无法解析这些返回类型。
然而，强制添加 requires transitive java.sql 并非推荐做法。它会将 SQL 实现细节过度暴露给上层模块（如 UI 层），违背封装原则和分层架构设计。更合理、更符合实践的方式是：限制数据库连接类的接口可见性，避免跨模块暴露 JDBC 原生类型。
✅ 推荐方案：降级方法可见性（推荐）
将 connect() 方法改为 包私有（package-private） ——即去掉 public 修饰符。这样该方法仅对同包内的类（如数据访问器 DataAccessor）可见，不构成模块对外契约，自然无需 transitive 依赖：
// dbConnect.java（修正后）
package mypackage;
import java.sql.*;
import java.util.Properties;
public class dbConnect {
static final String databaseDriver = "oracle.jdbc.driver.OracleDriver";
static final String databaseURL = "jdbc:oracle:thin:@localhost:1521:xe";
static final String username = "system";
static final String pass = "oracle";
private Connection connection;
private Properties properties;
// ✅ 包私有方法：不对外暴露 JDBC 类型
Connection connect() {
if (connection == null) {
try {
Class.forName(databaseDriver);
connection = DriverManager.getConnection(databaseURL, getProperties());
} catch (ClassNotFoundException | SQLException e) {
e.printStackTrace();
}
}
return connection;
}
private Properties getProperties() {
if (properties == null) {
properties = new Properties();
properties.setProperty("user", username);
properties.setProperty("password", pass);
}
return properties;
}
}同时，在同一包下定义封装良好的数据访问类，隐藏 JDBC 细节：
立即学习“Java免费学习笔记（深入）”；
// DataAccessor.java
package mypackage;
import java.sql.*;
import java.util.*;
public class DataAccessor {
private final Connection connection;
public DataAccessor() {
this.connection = new dbConnect().connect();
}
public List<String> getAllUsernames() throws SQLException {
List<String> users = new ArrayList<>();
String sql = "SELECT username FROM users";
try (Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(sql)) {
while (rs.next()) {
users.add(rs.getString("username"));
}
}
return users;
}
}⚠️ 注意事项：
- 使用
try-with-resources自动关闭Statement和ResultSet，避免资源泄漏；dbConnect类名建议遵循 Java 命名规范：首字母大写 →DbConnect；module-info.java中保持requires java.sql;即可（非transitive），因模块内部使用无需传递导出；- 若未来需支持多数据源或测试替换，可进一步抽象为接口（如
DataSourceProvider），配合依赖注入提升可维护性。
❌ 不推荐方案：启用 requires transitive java.sql
仅在极少数场景（例如你正在开发一个通用 JDBC 工具库，且明确要求下游模块直接操作 Connection）才考虑此方式：
// module-info.java（不推荐，仅作说明）
module myProject {
requires transitive javafx.graphics;
requires javafx.controls;
requires javafx.fxml;
requires javafx.base;
requires javafx.web;
requires transitive java.sql; // ← 此行使 java.sql 对所有依赖本模块的模块可见
opens mypackage to javafx.fxml;
exports mypackage;
}此举虽消除警告，但会导致模块耦合度升高，削弱架构清晰性，且可能引发运行时 IllegalAccessError（若客户端模块未正确声明 requires java.sql）。
总结
| 方案 | 可维护性 | 安全性 | 是否推荐 |
|---|---|---|---|
| 降级为 package-private 方法 | ✅ 高（封装良好） | ✅ 避免类型泄露 | ✅ 强烈推荐 |
添加 requires transitive java.sql
|
❌ 低（暴露实现） | ⚠️ 引入隐式依赖 | ❌ 不推荐 |
根本解决思路不是“让别人能访问 JDBC 类型”，而是“不让别人需要访问 JDBC 类型”。通过合理的分层与封装，让数据库操作收敛于数据访问层，即可彻底规避该警告，同时提升代码健壮性与可演进性。
