Java空指针25年亏掉10亿，这个编译器让老项目不用迁Kotl

1999年，Tony Hoare在ACM会议上道歉，说null是他"十亿美元的错误"。26年后，这个错误仍在Spring Boot代码库里疯狂复利——每当你写下if (user == null) return null;，就是在为这笔债务支付利息。

迁移到Kotlin？对大多数公司来说，这是把重写成本摊在PPT上的会计魔术。JADEx的作者显然算过这笔账：与其让整个工程团队学习新语言，不如让编译器替你做脏活。

一个文件扩展名，两套语法糖

JADEx的核心设计是.jadex源文件。非空是默认态，可空需要显式打标——这和Kotlin的逻辑一致，但作者刻意压低了迁移门槛。

看这段对比。传统Java的防御性编程：

public String getUsername(User user) {
if (user == null) return null;
if (user.getProfile() == null) return null;
return user.getProfile().getUsername();
}

同样的逻辑，JADEx版本：

public String? getUsername(User? user) {
return user?.profile?.username;
}

?标记可空类型，?.操作符链式安全访问。编译器会在你漏掉问号时拦下你，而不是等到生产环境凌晨三点报错。

Elvis操作符?:提供默认值回退：

String? name = repository.findName(id);
String display = name?.toUpperCase() ?: "UNKNOWN";

作者放出了一个完整的Spring Boot CRUD示例项目，覆盖控制器、服务层、仓库层——正是null传播和可变状态造成最多实际损害的分层架构场景。

readonly：把final从体力劳动变成默认配置

Java的final关键字是个典型的"正确但麻烦"设计。大型代码库里，意外重赋值是沉默的bug类别，但没人愿意在每个字段前敲final。

JADEx的解法是一行指令翻转默认：

apply readonly;
public class OrderService {
private int total = 0; // 隐式final，重赋值编译报错
private mutable int retries; // 显式声明可变
}

这个设计哲学和null安全一致：让安全路径成为阻力最小的路径。需要可变时，你得主动说mutable——这和Java里主动说final的 cognitive load（认知负担）正好相反。

编译输出是纯Java，带JSpecify注解。这意味着NullAway、Checker Framework等现有工具链能无缝接入，不需要fork整个生态。

Gradle插件已上线，IntelliJ插件另附

作者把Gradle插件丢进了Gradle Plugin Portal，IDE支持单独分发。这种拆分很产品经理思维：构建环节是刚需，IDE增强是体验加分，解耦后各自迭代。

技术实现上，JADEx是源到源编译器（source-to-source compiler）。没有JVM修改，没有运行时依赖，生成的字节码就是普通Java。这对需要过安全审计的企业环境是硬性优势——引入Kotlin编译器可能要重新走一遍供应链审查，JADEx不需要。

「零学习曲线」是作者的原话。这个说法在营销层面略显乐观——团队仍需理解可空类型的传播规则，readonly模式下的心理模型切换也需要适应期。但相比完整迁移到Kotlin，摩擦成本确实不在一个数量级。

项目仓库里那个Spring Boot示例值得细看。它展示了两种特性在真实分层架构中的协同：控制器接收可空参数，服务层用Elvis操作符处理默认值，仓库层返回带注解的实体。这不是语法演示，是迁移路径的样板间。

Hoare的十亿美元账单，Java社区已经分期付款25年。JADEx提供的是一种"债务重组"方案：不用破产清算（重写），不用借新还旧（迁Kotlin），直接在现有资产上加装防护层。

你会在一个新文件扩展名上押注生产代码的稳定性吗，还是宁愿继续写那些永远测不完的null检查？