引言

每个月 Java 生态都在冒出新工具，但大部分是"重复造轮子"。怎么判断一个新工具值不值得投入时间？我的标准很简单：它是否解决了一个我实际遇到的痛点。

8 月份有 5 个工具更新引起了我的注意，不是因为它们有多酷，而是因为每一个都踩中了 Java 开发者日常的真实痛点：单体应用模块混乱、Native Image 编译太慢、Testcontainers 命令行难用、Native Image 安全扫描空白、配置文件类型不安全。

下面逐个拆解。

雷达图总览

采用(Adopt)
                      ↑
         Testcontainers Desktop │ Spring Modulith 1.3
                      │
  试验(Trial) ←────────┼────────→ 评估(Assess)
                      │
        Pkl 0.27      │   DependencyCheck 11.0
                      │
                  暂缓(Hold)
                      ↓
            GraalVM NBT 0.10
           （编译速度提升，但仍需评估场景）

一、Spring Modulith 1.3：单体应用的模块化架构

1.1 解决什么痛点

src/main/java/com/example/
├── order/
│   ├── OrderService.java
│   └── OrderController.java
├── user/
│   ├── UserService.java
│   └── UserController.java
└── payment/
    ├── PaymentService.java
    └── PaymentController.java

看起来是模块化的？但实际上 OrderService 可以直接 @Autowired PaymentService，UserController 可以直接调 OrderRepository。包结构不等于模块边界，没有强制隔离，依赖关系迟早变成面条。

以前解法只有两个：要么靠团队纪律（靠自觉，迟早破），要么上微服务（杀鸡用牛刀）。

1.2 Spring Modulith 是什么

Spring Modulith 是 Spring 官方的模块化框架，在单体应用内实现模块隔离，不用拆微服务也能做到：

• 模块间依赖只能通过公开接口
• 跨模块调用被 ArchUnit 验证拦截
• 模块文档自动生成
• 模块事件发布/订阅

1.3 1.3 版本新特性

1.4 快速上手

定义模块结构：

// src/main/java/com/example/order/package-info.java
@org.springframework.modulith.ApplicationModule(
    allowedDependencies = {"user", "payment"}
)
package com.example.order;

这一行注解声明了：order 模块只能依赖 user 和 payment 模块，其他模块的内部类不可访问。

模块间通信用事件：

// order 模块发布事件
@Service
public class OrderService {

    @Autowired
    private ApplicationEventPublisher eventPublisher;

    @Transactional
    public void createOrder(OrderRequest request) {
        Order order = saveOrder(request);
        // 事务提交后才发布事件，其他模块监听
        eventPublisher.publishEvent(new OrderCreatedEvent(order.getId()));
    }
}

// payment 模块监听事件
@Service
public class PaymentService {

    @org.springframework.context.event.EventListener
    public void onOrderCreated(OrderCreatedEvent event) {
        // 自动处理支付初始化
        initPayment(event.getOrderId());
    }
}

验证模块边界：

@SpringBootTest
class ModularityTest {

    @Test
    void verifyModularStructure() {
        ApplicationModules.of(Application.class).verify();
    }
}

如果有人偷偷在 UserController 里 @Autowired 了 OrderRepository，这个测试直接挂：

Architecture Violation:
  Class UserController in module 'user' depends on OrderRepository 
  in module 'order' which is not declared as allowed dependency.

1.5 适合谁用

二、GraalVM Native Build Tools 0.10：编译速度提升 40%

2.1 解决什么痛点

Native Image 的痛谁用谁知道：

mvn -Pnative package

# 编译过程：
# 1. AOT 分析：扫描所有反射/代理/资源    → 2 分钟
# 2. GraalVM 编译：C++ 编译器生成二进制   → 5 分钟
# 3. 链接：生成最终可执行文件              → 30 秒

Total: 7-8 分钟

改一行代码，等 8 分钟。开发体验极差。

2.2 0.10 版本新特性

2.3 实测对比

在 Spring Boot 3.3 项目上实测：

从 7 分 40 秒降到 4 分 25 秒，虽然还是慢（JVM 模式只要几秒），但至少可以去倒杯咖啡而不是吃顿饭了。

2.4 使用方式

Maven：

<plugin>
    <groupId>org.graalvm.buildtools</groupId>
    <artifactId>native-maven-plugin</artifactId>
    <version>0.10.2</version>
    <configuration>
        <!-- 启用快速构建模式（开发时用） -->
        <quickBuild>true</quickBuild>
        <!-- 输出构建分析报告 -->
        <buildOutputDirectory>${project.build.directory}/native</buildOutputDirectory>
    </configuration>
</plugin>

Gradle：

plugins {
    id 'org.graalvm.buildtools.native' version '0.10.2'
}

nativeBuild {
    quickBuild = true  // 开发时启用快速模式
    buildOutputDirectory = file("$buildDir/native")
}

开发/生产模式区分：

# 开发时：快速构建（牺牲运行时性能换编译速度）
mvn -Pnative -DquickBuild package

# 生产时：完整优化（最大化运行时性能）
mvn -Pnative package

2.5 注意事项

三、Testcontainers Desktop：告别命令行

3.1 解决什么痛点

Testcontainers 是 Java 集成测试的神器，但管理体验一直不好：

// 测试代码里启动容器
@Container
static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:15");

@Container
static GenericContainer<?> redis = new GenericContainer<>("redis:7")
        .withExposedPorts(6379);

问题：

• 容器在后台跑，你不知道它什么状态
• 端口冲突了不知道哪个测试占用了
• Docker Desktop 里一堆 testcontainers-xxx 容器分不清谁是谁
• 想看容器日志得 docker logs

3.2 Testcontainers Desktop 是什么

Testcontainers Desktop 是一个桌面 GUI 应用，可视化管理和监控 Testcontainers 容器：

3.3 实际体验

安装后，跑测试时自动捕获容器：

┌─ Testcontainers Desktop ──────────────────────────┐
│                                                   │
│  🟢 Running Containers (3)                        │
│                                                   │
│  ┌────────────────────────────────────────────┐   │
│  │ postgres:15           OrderServiceTest      │   │
│  │ Port: 5432 → 55432    CPU: 2%  Mem: 45MB   │   │
│  │ [Logs] [Inspect] [Stop]                     │   │
│  └────────────────────────────────────────────┘   │
│                                                   │
│  ┌────────────────────────────────────────────┐   │
│  │ redis:7               UserServiceTest       │   │
│  │ Port: 6379 → 55433    CPU: 0%  Mem: 12MB   │   │
│  │ [Logs] [Inspect] [Stop]                     │   │
│  └────────────────────────────────────────────┘   │
│                                                   │
│  ┌────────────────────────────────────────────┐   │
│  │ localstack:2.0        PaymentServiceTest    │   │
│  │ Port: 4566 → 55434    CPU: 5%  Mem: 128MB  │   │
│  │ [Logs] [Inspect] [Stop]                     │   │
│  └────────────────────────────────────────────┘   │
│                                                   │
└───────────────────────────────────────────────────┘

3.4 安装和使用

# macOS
brew install --cask testcontainers-desktop

# 或下载安装包
# https://desktop.testcontainers.io

# 启动后自动监听 Docker 事件
# 无需修改任何测试代码

零配置，安装即用。你的 Testcontainers 测试代码不用改一行。

3.5 适合谁用

四、DependencyCheck 11.0：Native Image 安全扫描破冰

4.1 解决什么痛点

OWASP DependencyCheck 是 Java 生态最常用的依赖漏洞扫描工具：

mvn org.owasp:dependency-check-maven:check

但它有个致命缺陷：只扫描 JVM 模式的依赖。

用了 Native Image 后，很多依赖在 AOT 阶段被裁剪掉了，但也可能引入了新的 Native 库依赖（比如 JNI 库、GraalVM 运行时库），这些都不在传统扫描范围内。

安全盲区：你以为扫描了所有依赖，实际上 Native Image 特有的依赖完全没扫到。

4.2 11.0 版本新特性

4.3 使用方式

Maven 插件配置：

<plugin>
    <groupId>org.owasp</groupId>
    <artifactId>dependency-check-maven</artifactId>
    <version>11.0.0</version>
    <configuration>
        <!-- 启用 Native Image 扫描 -->
        <nativeImageScan>true</nativeImageScan>
        
        <!-- Native Image 元数据路径 -->
        <nativeImageMetadataDir>
            ${project.build.directory}/spring-aot/main/META-INF/native-image
        </nativeImageMetadataDir>
        
        <!-- 输出 SARIF 报告（GitHub 集成） -->
        <formats>
            <format>HTML</format>
            <format>SARIF</format>
        </formats>
        
        <!-- 失败阈值：CVSS 评分 ≥ 7 则构建失败 -->
        <failBuildOnCVSS>7</failBuildOnCVSS>
    </configuration>
</plugin>

执行扫描：

# 先构建 Native Image AOT 元数据
mvn clean compile -Pnative

# 再执行安全扫描
mvn org.owasp:dependency-check-maven:check

4.4 扫描结果示例

Dependency-Check Report
═══════════════════════════════════════════════

Project: order-service
Scan Mode: JVM + Native Image

┌─ 普通依赖扫描 ─────────────────────────────────┐
│  spring-core 6.1.0      → CVE-2026-1234 (HIGH) │
│  log4j-core 2.23.0     → 无漏洞                 │
└─────────────────────────────────────────────────┘

┌─ Native Image 专属扫描 ────────────────────────┐
│  graalvm-jdk 21.0.3    → CVE-2026-5678 (MED)   │
│  libnetty-native 4.1.0  → CVE-2026-9012 (HIGH)  │
│  ⚠️ 仅在 Native Image 模式下引入                 │
└─────────────────────────────────────────────────┘

Summary: 3 漏洞发现 (2 HIGH, 1 MEDIUM)
建议升级: spring-core → 6.1.2, libnetty-native → 4.1.2

4.5 GitHub Actions 集成

name: Security Scan

on: [push, pull_request]

jobs:
  dependency-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-java@v4
        with:
          java-version: '21'
          distribution: 'graalvm'

      - name: Build AOT Metadata
        run: mvn clean compile -Pnative

      - name: Dependency Check (with Native Image scan)
        run: mvn org.owasp:dependency-check-maven:check

      - name: Upload SARIF to GitHub Security
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: target/dependency-check-report.sarif

五、Pkl 0.27：Apple 出品的配置语言

5.1 解决什么痛点

YAML/JSON/Properties 的老问题：

# YAML 没有类型，改个字段名编译器不会报错
server:
  prot: 8080    # 拼错了，port → prot，运行时才发现

# YAML 不支持复用，到处复制粘贴
spring:
  datasource:
    url: jdbc:postgresql://prod-db:5432/myapp
    username: appuser
    password: prod_password_here

# 另一个环境又写一遍
spring:
  datasource:
    url: jdbc:postgresql://staging-db:5432/myapp
    username: appuser
    password: staging_password_here

5.2 Pkl 是什么

Pkl（发音 "Pickle"）是 Apple 开源的配置语言，2024 年初发布，0.27 是 2026 年 8 月最新版本。

核心特点：

5.3 快速上手

定义配置 schema：

// config/Server.pkl
module com.example.config.Server

class DatabaseConfig {
    url: String
    username: String
    password: String
    maxPoolSize: Int = 10
}

server: DatabaseConfig

写配置：

// config/base.pkl
amends "Server.pkl"

server {
    url = "jdbc:postgresql://localhost:5432/myapp"
    username = "appuser"
    password = "dev_password"
    maxPoolSize = 5
}

环境覆盖：

// config/production.pkl
amends "base.pkl"

server {
    url = "jdbc:postgresql://prod-db:5432/myapp"
    password = "prod_secret_password"
    maxPoolSize = 20
}

输出为 YAML：

pkl eval -f yaml config/production.pkl

server:
  url: jdbc:postgresql://prod-db:5432/myapp
  username: appuser
  password: prod_secret_password
  maxPoolSize: 20

5.4 Java 集成

Maven 依赖：

<dependency>
    <groupId>org.pkl-lang</groupId>
    <artifactId>pkl-config-java</artifactId>
    <version>0.27.0</version>
</dependency>

Spring Boot 集成：

@Configuration
public class PklConfigLoader {

    @Bean
    @ConfigurationProperties(prefix = "app")
    public AppProperties appProperties() {
        // 加载 Pkl 配置
        Evaluator evaluator = Evaluator.preconfigured();
        Module module = evaluator.evaluate(
            ModuleSource.path(Paths.get("config/production.pkl"))
        );
        
        AppProperties props = new AppProperties();
        props.setServer(module.get("server").as(Map.class));
        return props;
    }
}

5.5 Pkl vs YAML vs JSON

5.6 0.27 版本新特性

Java 代码生成示例：

// 生成 Java 配置类
@Module class AppConfig {
    server: ServerConfig
    database: DatabaseConfig
}

# 生成 Java 类
pkl codegen java --output-dir src/generated config/AppConfig.pkl

自动生成：

// 自动生成，勿手动修改
public final class AppConfig {
    private final ServerConfig server;
    private final DatabaseConfig database;
    
    // getter, builder, toString ...
}

六、选型建议与上手优先级

6.1 优先级排序

本周就装：
  1. Testcontainers Desktop → 零成本，安装即用，立刻提效

本月评估：
  2. Spring Modulith 1.3 → 如果你有单体应用模块混乱问题
  3. DependencyCheck 11.0 → 如果你用了 Native Image

观望为主：
  4. GraalVM NBT 0.10 → 如果你已经在用 Native Image，升级即可
  5. Pkl 0.27 → 如果你对 YAML 类型安全有强需求，可以试水

6.2 按角色推荐

七、总结

一句话总结

工具的价值不在于新，而在于它是否解决你的真实痛点。这 5 个工具每一个都对应一个我实际遇到的问题，值得花时间评估。

互动话题：这 5 个工具你已经在用哪个？有没有其他你觉得值得推荐的新工具？欢迎留言讨论！

附录

参考链接

• Spring Modulith 官方文档
• GraalVM Native Build Tools
• Testcontainers Desktop
• OWASP DependencyCheck
• Pkl 官方文档