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检查？
热门跟贴