过去、现在和未来 —— Java 的现代化之路
Java ，一门广受赞誉，却又饱受诟病的语言，在从其诞生至今，便无时不刻的被于其他语言对比，有时候这种对比是空穴来风的诽谤，但更多的是对这门语言未来的担心，而近 10 年来涌现的一个又一个新生的程序语言更是让 Java 一次又一次地被推上风口浪尖，使公众一次又一次的质疑：Java ，是否真的停滞不前了？
2024 年，从大街上随便抓一个 Java 程序员，询问其 Java 有哪些槽点，我相信你的这个下午大概是别想离开这个人的声音了 —— 从泛型不支持基本数据类型到各种各样令人抓耳挠腮的奇怪问题，你绝对可以听这个人滔滔不绝地说上一整天。那么这些问题 Java 官方知道吗？当然知道，他们在解决吗？ Ummm ，至少我们可以说，他们一直以来都正在积极的为解决这些问题而努力，并且有些槽点，其实早已在最新版本的 Java 中被解决。
因此，本篇文章的目的，便是带领读者从过去走向现在，再走向未来，回顾并前瞻 Java 已经推出，或是即将推出的全新特性，这些特性再 Java 的历史中都扮演着决定性的作用，为 Java“赶 Go 超 Rust”贡献着自己的努力。
碍于篇幅所限，我们将只重点提及几个 Java 语言史上的重大改动，而其他小的（但不代表不重要）更新，我们姑且一概掠过。若要了解 Java 从过去到现在全部的特性更新，也许你可以看看 OpenJDK 的 Java 特性提案索引页 JEP 0: JEP Index，了解更多。
Java8：Lambda 表达式和 Stream API
Java 8 无论是从 JVM 层面的变动，还是 Java 语法和标准库的变动，都可以说是 Java 有史以来第一次大规模的增补，毋庸置疑的，这次更新也为 Java 带来了第二春，使之焕发新生，而其长达近 20 年的 LTS 支持，也使其成为了 Java 历史上使用率最高，最经久不衰的 Java 版本。
在这次更新中，Java 自然是引入了全新且复杂的 Date & Time API ，看起来好像有点用但实际上很鸡肋的 Optional API 这类谈不上小但是也很难说重大的标准库修补。但是更为被人津津乐道，且在本人看来是 Java 8 最重要的两个更新，便是 Lambda 表达式和 Stream API 。
Lambda 表达式
也许是考虑到兼容性，也许就是纯粹 Java 开发者懒，自 Java 7 以前，Java 虚拟机（ JVM ）基本没有什么重大改动，纵然 Java 语言已经引入了诸如自动拆装箱、参数化类型（泛型）这样的重大语言特性，JVM 依然不动如山，全靠 javac 衬托。
然而到了 Java 7 ，天塌了。JVM 引入了一个全新的指令 invokedynamic，其可以在运行时动态的分派一个函数调用，这个指令最初并没有被 Java 语言本身所使用，相反，它的出现是为了解决基于 JVM 的动态类型语言（例如 Groovy ）在运行时由于 JVM 无法支持函数类型动态分派而导致的巨大性能问题。
而这个指令第一次在 Java 语言中登场，便是神奇的 Lambda 表达式了。
即使你不知道 Lambda 表达式，或者他背后的函数式接口，我相信你一定写过这样的代码：
new Thread(() -> Foo.bar()).start(); // 更好的一个写法其实是 new Thread(Foo::bar).start();

这很自然，就像你可能不会泛型编程，但一定也用过带泛型的 Java 容器一样。但如果我告诉你，在过去的 Java 版本中，人们只能这么写：
new Thread(new Runnable() {
@Override
public void run() {
Foo.bar();
}
}).start();

是不是会有一种天然的碰见庞然大物的恐惧感。而事实上，在 Java 8 以前，函数式编程是不可能的，这主要源自于 Java 的一个语法缺陷：在 Java 中，函数（方法）不是一等公民。
什么是“一等公民”？来看看在 JavaScript 中大家习以为常的一段代码：
function foo(){
console.log("foo!");
}

function bar(barFoo){
barFoo();
}

bar(foo);

最后一行中，我们为 bar 函数直接传入 foo 函数作为其实参，并在 bar 函数中调用这个函数。我们可以将一个函数（或者说，函数指针）作为参数传入到函数中，就像其他数据类型一样。
但是 Java 是没有办法直接传入函数指针的，如果你了解 C＃ 的话，C＃ 用 Delegate（委托）机制解决这个问题，而 Java 则绕的更远一些，选择了 Functional Interface（函数式接口）作为其函数式编程的解决方案。那么，什么是函数式接口？
通俗的来讲，任意一个仅有一个抽象方法的接口，都是函数式接口（无论其是否标注 @FunctionalInterface 注解），例如我们上边看到的 Thread 构造方法中的 Runnable 接口：
@FunctionalInterface
public interface Runnable {
/**

• When an object implementing interface Runnable is used
• to create a thread, starting the thread causes the object's
• run method to be called in that separately executing
• thread.
• The general contract of the method run is that it may
• take any action whatsoever.
  *
• @see java.lang.Thread＃run()
  */
  public abstract void run();

}

这个接口只有一个名为 run 的抽象方法，并没有任何返回值。我们可以为需要函数式接口实例的地方传入 Lambda 表达式，在运行时，Lambda 表达式会被转换为对应函数式接口的实例，就像我们为 Thread 传入构造函数参数所做的那样一样。
当然，请不要误解我的意思，并不是自 Java 8 引入函数式接口这个概念之后，才有了 Runnable 接口，相反，Runnable 接口古早有之，是函数式接口的概念被引入后，Runnable 也正巧成为了函数式接口的一部分。
Stream API
Lambda 表达式的一大创新之处，就是为在 Java 语言进行函数式编程提供了可能，由此，Stream （流） API 应运而生。这里所说的“流”并不是指 I/O 流，而是一种数据流动的管道。举个例子，现在有一个包含 10000 个数字的 int 数组：
int[] array = new int[10000];

我想找出该数组中所有数字大于 5000 的数字，然后让他们加一个不大于 500 的随机数，最后求和。在不使用 Stream API 的情况下我们会这么写：
public int sumRandomNumber(int[] array, Random random){
int rst = 0;
for (int i : array) {
if (i > 5000) {
rst += i + random.nextInt(500);
}
}
return rst;
}

但如果有了 Stream API ，只需要一行代码就可以解决：
public int sumRandomNumberWithStreamAPI(int[] array, Random random) {
return Arrays.stream(array).filter(i -> i > 5000).map(i -> i + random.nextInt(500)).sum();
}

在上述代码中，我们通过调用 Arrays.stream 方法将 array 转换为一个 IntStream 流对象，然后顺次调用 filter 和 map 流中间方法，过滤和映射数据，最终调用 sum 流终结方法，获得求和结果。
一种特定类型的数据经过流中间方法的加工处理，最终经过流终结方法收集为我们想要的形式，这极大地提高了开发效率，而在以前的 Java 中，想要达成这样的操作，会使代码变得极度复杂。
Project Loom：Java 迈向现代化的第一步
相信各位对“Coroutine （协程）”这个名词一定不陌生，被称为“轻量级线程”的它，在 I/O 密集型的应用程序开发领域可谓是如日中天。所谓“协程”，便是一种用户态的线程，它们构建于线程之上，由用户程序负责调度，而不是操作系统。比起原生的操作系统线程，他更轻量，而比起 Event Loop （事件循环）的解决方案，它又能保证对用户程序足够透明，降低开发过程中的心智负担。
许多现代语言都配备了协程的原生支持，尽管它们各自的实现方式并不相同，例如 Go 的 Goroutine，Kotlin 的 Kotlin Coroutines 或是 C++ 20 的 Coroutines。在早期版本的 Java 中，其实有一个名为“Green thread （绿色线程）”的协程实现，但因为各种原因，最终被替换回了现在的操作系统线程。
但是我们确实需要协程，于是 2017 年，Project Loom 应运而生，它的使命就是为 Java 提供自己的有栈协程实现，早期被称为“Fiber （纤程）”，后被称为“Virtual thread （虚拟线程）”，经过两个大版本的预览，其终于在 Java 21 中正式推出，这意味着 Java 平台也拥有了自己的原生协程实现。
于是现在，你可以通过 Thread 对象的静态工厂方法 ofVirtual 创建一个虚拟线程:
Thread.ofVirtual().start(()->{
// some heavy IO stuff
});

就是这么简单，如果你在用 Spring Boot 3 ，只需要一行配置便可以在你的项目中启用虚拟线程支持：
spring.threads.virtual.enabled=true

很简单对不？现在就去试试看吧，我保证带来的性能提升是立竿见影的。
当然有关并发编程，另一个绕不开的话题便是异步编程了，Java 目前原生的异步编程由 Future 等对象支持，用起来不能说十分好用，只能说味同嚼蜡。在 Java 19 引入的 Structured Concurrency （结构化并发）事实上在一定程度上为异步编程提供了更好的解决方案，篇幅所限，在这里我们也不再展开。
Project Panama：外地人向本地人的妥协
长期以来，Java 一直以“一次编写，到处运行”作为自己的卖点，然而很不幸的是，Java 没能向开发者提供所有他们想要的原材料，因此，开发者们决定自己做，最终，在各种 JNI 函数和 Unsafe 调用的狂轰滥炸下，Java 最终还是变成了“一次编写，到处调试”的样子。
JNI 好用吗？我相信没人会说好用，不然也不可能会有 JNA 一类的库出现，JNI 看似提供了 Java 向 native 调用的接口，但实际上它完全不够灵活，无法在运行时根据程序的需要动态的链接不同的函数。自 Java 1.1 引入 JNI 开始，这个东西就基本没什么变化，大家只能捏着鼻子用这样一套并不好用的东西，或者只能叹叹气，然后另寻他法。
再回过头来看看 Unsafe ，在过去版本的 Java 中，管理堆外内存是非常复杂且危险的，尤其是当我们通过 hacky 的方式获取 sun.misc.Unsafe 类实例，并使用其中的 allocateMemory 方法来分配堆外内存时。这意味着，我们需要手动管理这些堆外内存的分配和释放，一不小心，就可能造成 JVM 虚拟机和 GC 无法处理的内存泄漏。
有些人可能会说：JVM 本来就不希望你使用堆外内存，你为什么要这么用，这不是自找没趣吗？但是很遗憾的是，有时要想获得高性能的数据吞吐或是确保数据的一致性，我们不得不这么做，例如在 Java 中使用 mmap, CAS ，或是设置内存屏障。在 Java 8 ，如果你想设置一个操作系统级别的重量级锁，你可以使用 LockSupport.park；自 Java 9 开始，如果你想对一个对象中的字段 CAS 写入，则可以用 VarHandle.compareAndSet 方法；但是其他 JVM 未能提供的操作，也许你只能像使用 JNI 一样，绕一个大圈，或是看看社区上有没有已经做好的，也许可能充满各种漏洞的小玩具。
但是事情还是需要解决的，最终这场争端以 Java 这个外地人向本地人的妥协而告终：Project Panama 应运而生。经过三个大版本的预览，Project Panama 的一个重要特性，The Foreign Function & Memory (FFM) API 终于在 Java 22 正式落地。FFM API 有什么用？首先，它可以提供灵活的本地库访问：
Linker linker = Linker.nativeLinker();
SymbolLookup stdlib = linker.defaultLookup();
MethodHandle strlen = linker.downcallHandle(
stdlib.find("strlen").orElseThrow(),
FunctionDescriptor.of(ValueLayout.JAVA_LONG, ValueLayout.ADDRESS)
);

try (Arena arena = Arena.ofConfined()) {
MemorySegment cString = arena.allocateFrom("Hello");
long len = (long)strlen.invokeExact(cString); // 5
}

上述代码创建了一个操作系统标准库的链接器，在其中查找 strlen 函数并以一个从 JVM 创建的堆外字符串作为参数执行，获取结果。在这个过程中，还需要告诉 JVM 函数和参数的内存布局，以便 JVM 可以正确传入他们。
接下来，FFM API 向我们提供了更适合 Java 宝宝的堆外内存 API ，Arena ，你可以通过这种方式创建一个会自动被 GC 清理的堆外内存：
MemorySegment segment = Arena.ofAuto().allocate(100, 1);
...
segment = null; // the segment region becomes available for deallocation after this point

或者，你可以直接创建一个基于作用域的堆外内存，并使用 try-with-resource 语法包裹，只要离开 try 作用域，则分配的堆外内存会被自动释放：
MemorySegment segment = null;
try (Arena arena = Arena.ofConfined()) {
segment = arena.allocate(100);
...
} // segment region deallocated here
segment.get(ValueLayout.JAVA_BYTE, 0); // throws IllegalStateException

别忘了 mmap，现在 FFM API 可以直接提供这种支持，只需要调用 FileChannel.map 方法即可：
Arena arena = Arena.ofAuto();
try {
try (FileChannel channel = FileChannel.open(Path.of("large_file"), StandardOpenOption.READ)) {
MemorySegment segment = channel.map(FileChannel.MapMode.READ_ONLY, 0, FILE_SIZE, arena);
// use segment in your way
}
} catch (IOException e) {
throw new RuntimeException(e);
}

是不是简简又单单呢？有了 FFM API 这把瑞士军刀，相信以后 Java 能做的事情会更有趣和疯狂。
Project Valhalla：走向未来
至此，我们已经介绍完了 Java 走向现代化三座大山中已经落地的前两座，如你所见的是，他们每一个都充满诱惑，十分大胆，令 Java 焕发新生，但是 Project Valhalla 将带给我们的，比前面我讲过的那些特性更加疯狂，更加颠覆：为 Java 引入值类型对象，补上长久以来 Java 泛型编程的缺陷，并为 JVM 虚拟机提供运行时可见的泛型参数。
让我们先来回忆一下泛型的前世今生：泛型于 Java 1.5 被首次引入，其更官方、也更直观的名称应该是 Parameterized Type （参数化类型），其允许将类型作为类或函数的参数提供，以便于更好的进行类型检查或是根据不同的泛型特化代码实现，然而后者并不被 Java 泛型所支持，因为 Java 泛型采用的方案于 C++, Go, Rust 这些语言的泛型方案有本质不同：Java 的泛型只是编译器语法糖，在运行时并没有影响代码执行，这意味着，当你在 C++ 中使用 Vector 和 Vector 时，C++ 编译器事实上会生产两个不同版本的 Vector 类（这也是其名称“模板”的由来），但 Java 并不会改变这一点，List 和 List 和其未泛化原始类型 List 没有任何差别，编译器会在需要提供或返回泛型参数时帮你做类型安全检查或自动类型转换，而 JVM 不会感知到泛型的存在。
泛化泛型和具化泛型的争端从未停止，本文也无心讨论此两者之间各自的优劣，但是不可否认是，泛化泛型确实为 Java 引入了一个难以逾越的语法鸿沟：那就是参数化类型无法接受基本数据类型作为参数，这意味着在 C＃ 程序员严重看起来十分正常的代码：
List list = new List<>();

在 Java 中是不可能的。而长久以来，Java 程序员只能被迫在需要将基本数据类型放入集合的场景下进退两难：要么把 int 装箱成 Integer，忍受额外的对象创建开销；要么自行构建，或者使用各种工具库提供的特化集合类型（例如 IntArrayList, DoubleArrayList 等）。而事实上，这种语法鸿沟在 Java 中由来已久，例如 switch 语句不支持 double 等类型，instanceof 关键字不支持针对基本数据类型的模式匹配等，颇令新手疑惑，好在在最近的版本（ Java 23 ）中，这些问题都逐步得到完善，进入预览的流程。
再回过头来看看基本数据类型的装箱机制，这实际上是十分不明智的，因为基本数据类型这种可能被程序大量使用的数据，他们本应将其数值直接存储到内存中，而不是被包装一个含有比他们实际内容更为复杂的对象和对象头，这无疑增加了系统的内存压力。而参数化类型对基本数据类型的缺位更是加剧了这一问题。
为此，Project Valhalla 横空出世，直指这些痛点问题，并推出了它们的解决方案：值类型和通用泛型。
在未来的 Java 版本中，我们将可以通过 value class 标识创建一个值类型类：
value record Color(byte red, byte green, byte blue) {} // 值记录类型

这种类型没有对象头，其 hashCode 直接据其所含字段计算，这同时也意味着，对值类型进行 == 比较将会比较其值，而不是其地址。在未来，所有的基本数据类型包装类都会被升级为这种值类型。而原本的类型将会被称为 Identity class ，意为具有身份的类型。
而通用泛型（这是一个早前叫法，但我觉得放到这里更直观，所以接着沿用下来）将允许我们在未来在泛型中直接使用基本数据类型作为泛型参数，而这种实现有可能依然是通过自动拆装箱实现的。
如果你恰巧用过 Java 16 及以上的版本，你可能会发现有一个新特性和上述特性有点类似，那就是 Record （记录）类型，该特性允许你通过简单的语法创建一个不可变的 POJO 对象，并为其实现 equals/hashCode/toString 方法和构造函数，而不必由你手动实现，或是使用额外的 @lombok.Data 和 @lombok.AllArgsConstructor注解：
record Point(int x, int y) { } // 通过 new Point(0, 0) 构造，通过 point.x()/point.y() 访问

但实际上，record 和 value class 是有本质区别的。Record 本质上还是一个对象，他依然是一个特殊的语法糖，并没有改变对象的本质；而 value class 则彻底颠覆了 Java 原有的对象模型。
除此之外，Project Valhalla 还有一些很有意思的提案，例如为 JVM 添加可 null 和非 null 类型，就将 C＃ 和 Kotlin 所做的那样；亦或者在运行时保留泛型参数，提供特化类型的实现等。
最后要说的是，Project Valhalla 的相关提案仍在不断更新，早在草案时期，相关提案就已被推翻重置了多次，因此对于该提案的相关描述在未来可能会是不准确的，希望读者悉知。
引用

JEP 444: Virtual Threads (openjdk.org)

JEP 454: Foreign Function & Memory API (openjdk.org)

JEP 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal (openjdk.org)

java.lang.foreign (Java SE 22 & JDK 22) (oracle.com)

Arena (Java SE 22 & JDK 22) (oracle.com)

FileChannel (Java SE 22 & JDK 22) (oracle.com)

Project Valhalla (openjdk.org)

JEP 395: Records (openjdk.org)

JEP 401: Value Classes and Objects (Preview) (openjdk.org)

JEP 402: Enhanced Primitive Boxing (Preview) (openjdk.org)

JEP 455: Primitive Types in Patterns, instanceof, and switch (Preview) (openjdk.org)

写的很好新手也能看得懂😎

现在 java 程序员是不是只有 8 版本才能用阿？那这么多新特性都用不上了。很可惜、还有感觉上 java 必须要学 spring 这个框架好像语言部分看轻了。很多人都自嘲说是 spring 程序员。

干一杯，想不到还有人关心我大 Java

java 90%+的工种是后端开发，后端对于 java 最成熟，经过无数企业实践，功能最全，糊代码最快，解决方案最多，出了问题最好搜答案的框架就是 spring 。

抛开 spring 谈 Java ，就像抛开抛开 oob 用 c++，何苦来哉。

Project Valhalla 这大饼画了多少年了都🤣

好文章

写的真不错

文章不错，但 Java 的坏名声很多并不是因为语言本身，而是因为充斥坏味道、抱残守缺和最差实践的社区和开发者吧。Stream 和 Optional 都是不错的设计（ Optional 存疑，是否值得在一个实用目的的语言里使用如此显明的方式，为什么不像别的语言一样通过修改语法让程序员无感呢），但是截至如今，一大批程序员对这两个基本库都是抵制状态，「 stream 太复杂看不懂」「 optional 脱裤子放屁」之类的话语，哪怕在这里也能看得到一大堆。「你发任你发」更是成为了一个梗。Java 语言社区的糟糕氛围也可见一斑吧。又比如社区对「业务、AI 、设计模式、微服务」 DDD 、敏捷」之类的东西的神秘迷恋，但对于语言和设计本身的讨论是缺失的。像 op 这种讨论语言本身的东西，在这个大环境下也只是叫好不叫座吧。我以前吐槽过 Java 的泛型和原始类型的问题，也很期待 Valhalla 能带来新的思路。其他 Java 程序员：你加个 comparator 不就行了。鸡同鸭讲。再好的语言，遇到一群不思进取的开发者，也难有好名声。

捉！又遇见佬了：）

其实我觉得，Java 现在这种样子我还挺喜欢的，虽然某些东西确实啰嗦，但就是简单明了，没有各种复杂的写法、语法糖什么的，不熟悉的一看也能明白个七七八八，搞那么多写法干嘛，Java 8 我已经很满意了。

最近翻轮子翻到某“古董项目”，其中有一个评论就一个词：“Java”🤣

不知道兄台哪里学的写作技巧，用一个词来形容：浮夸。随便摘选一段：> Project Valhalla：走向未来> 至此，我们已经介绍完了 Java 走向现代化三座大山中已经落地的前两座，如你所见的是，他们每一个都充满诱惑，十分大胆，令 Java 焕发新生，但是 Project Valhalla 将带给我们的，比前面我讲过的那些特性更加疯狂，更加颠覆……走向未来充满诱惑十分大胆焕发新生更加疯狂更加颠覆结果就一个值类型？这是几十年前被主动舍弃又捡回来的东西，和现代化能有多大关系？你这文章可不短，介绍的新特性可没几个。给你个建议，按照时间线把 Java 8 之后的大版本挨个过一遍，把主要新特性列出来，解释一下意义，重要的就多提一嘴。我相信这些新特性你自己也了解不全，否则也不至于列了这么多大标题小标题，最后拿出这几个东西来。作为作者，多花时间了解技术，创作内容，别把精力花在虚浮的“文笔”上。

我司就是写 Java 的，很多项目到现在还窝在 JDK6 甚至 7 的语法里还没有升级，主版本还是 8 ，升级到新 JDK 还很遥远……

个人写作风格，其实这些特性所做的事情确实十分大胆，即使他们表现在表面的东西并不多，但其实水下的冰山还是很深的。至于您说的后面那个建议，之前有写过一篇类似的文章，欢迎阅读: my.minecraft.kim/tech/268/%e5%a4%a7%e4%ba%ba%ef%bc%8c%e6%97%b6%e4%bb%a3%e5%8f%98%e4%ba%86%ef%bc%81%e4%bd%bf%e7%94%a8-java-16-%e6%88%96-kotlin-%e6%9b%b4%e5%a5%bd%e7%9a%84%e8%bf%9b%e8%a1%8c%e6%8f%92%e4%bb%b6%e6%88%96%e6%a8%a1/

那么....咱们什么时候升级 JDK 版本？等我死了？还是有一天直接换成 kotlin ？还是说梦里......

有大量的公司和程序员在坚守 你发任你发、我用 java8以致于很多人都不清楚 java8 以后的新特性，当看到 go 和 rust 的时候直接就放弃 Java 了

我总觉得，就别更新了，就这样吧，别折腾了。看看 C++都折腾成什么样子了。搞语言的人和搞 UI 的人没啥区别，都喜欢折腾。

去年干了一堆 migrate to jdk 17 的 ops task平心而论新的 jdk 肯定好但是真的值得那么多 effort 吗

spring 制造的问题比解决的问题多得多，业界毒瘤。

不管是写作风格，还是观点，我都不能认同。Java 前些年确实过于保守，但是这几年表现出来的“激进”，也都是基于其它语言的成熟经验。我看不出来有任何你说的“十分大胆”。如果说 Java 设计之初抛弃值类型尚可评价为“十分大胆”，在硬件大幅进步的今天又捡回来，只能说是一种无奈的妥协。只是实现上比较麻烦罢了。至于某个特性背后的实现有多难，水有多深，对于 Java 这样的体量来说，不是什么值得拿出来说的事。对开发者有多大影响，是衡量一个特性重要性的唯一标准。

讲真，我是不知道这些做后端的用 Java 8 怎么还好意思拿出来讲的。我做安卓的，最次的项目就算用的不是 Kotlin ，现在也是用的 Java 17 了。

讲个笑话，JAVA 要求把自己删除
Android 开发表示：现代化的 Java ，不就是 Kotlin 么

value class 是不是和 c++/c＃ struct 是一种东西

＃21 对于 JEP 那帮子老逼登来说，确实够大胆了

这玩意真的难学。搞个 nodejs golang 啥的，直接就糊过去了。现在哪有几家大型互联网需要大规模协作开发

第一次看到 Record 类型是在一个开源项目中，感叹 java 创建一个对象也能如此简洁了

以前虽然写过几年 java ，但应该不会再回去。印象中这语言不轻量，甚至都没有独立变量和函数，社区的库风格也是重量臃肿抽象化.

不错不错，还是很希望又有 Java 的生态，语言又现代化，所以直接上 Kotlin 了。

那我就要推荐一个现代化 java 技术栈脚手架了。make java great again -> www.mjga.cc

Project Panama 生动形象的展示了对于 Java 而言，修改语言来支持一些功能到底是多么难的事情。就现在那个 FFM API ，查找导入符号全靠运行时动态查找，数据布局全靠 API 在运行时动态定义，传入 Java 这边的回调也得先反射拿到 MethodHandle 再传递，然后在 native 和 managed 两边传递数据先复制过去再复制回来。就不说到处复制带来的严重效率问题，光那一大堆的运行时动态 API ，Java 这是不打算让 FFM API 在 AOT 下用了？还是说 AOT 之后要带个解释器用来处理 FFM 的各种符号绑定、数据布局和调用约定问题？

哥们是新人吧，java 17 21.9 发布的，新项目用最新的 tls 版本没问题， 但是有老项目啊， 难道你们的老项目也都迁移到 17 了？老项目不多可能会迁， 老项目多了，好多公司的领导层都不太想花成本去做这个迁移吧

怎么感觉是周志明大佬的演讲内容

大多数人没有动力去推动升级，即使 springboot2 已经不再维护了. 除非出现安全事故