2025 年 Java 才是究极体吗

这图哪来的，挺好看的就

这是从油管《 Java's Plans for 2022 - Inside Java Newscast #18 》那评论扒下来的吧。
这个 plan 只是那老哥“This is really just my personal guess. I don't ask the devs for their estimates because I'd either get the official, vague reply or I'd get details that I can't share. So all I know is from the JEPs, mailing lists, talks, etcetera. That means this is no official Oracle announcement, you can't trust a word I say (imagine safe harbor slide), and you better not base business decisions on my ramblings.”，
离“Java 的究极体”其实还远远远着呢，Java 就靠其生态圈吃饭，而 Loom 和 Valhalla 都是很比较激进的特性，就算正式发布了，等其生态做完适配都不知道猴年马月了，我倒是好奇会是它们的生态先成熟，还是柯南先大结局。

Amber 项目搞语法糖的，没啥好说。
Loom 项目个人没啥感觉，有迫切需求的要么切 go 了，要么上 reactor 了，协程对生态的不确定性还是太大，很多依赖库就靠线程才玩起来的（随便举个例子：日志的 MDC ）。很多老哥不习惯 reactor 那函数式编程，但这玩意就是“写熟了真香”，就靠传统的线程知识，玩 reactor ，玩线程如臂使指，很舒服。
而 Valhalla 那项目做得也太慢了，搞了快 10 年了，连 preview 都不敢发。就算将来当正式特性发布了（而不是 preview 特性），撑死就极个别上层应用敢用，等一些普适性的依赖库适配完，那估计得等到 2030 年，甚至我相信很多依赖库压根不愿意做适配。

总而言之，别抱啥希望在生产环境使用 loom 或 valhalla 做得特性，除非公司自己有能力自己打造一个生态。不过到有其他“生财之道”：1. 做培训； 2. 一些老哥不是感觉 Java 生态太全了，没啥可做了嘛。那就可以根据“新 Java”做全新的依赖库，把那些死气沉沉的古董依赖库弄出去，自己搞个牛逼的依赖库。特别一提，如果有人有兴趣，其实这条现在就可以开始做了。

就算你升到 3025 ，那也是 Java 8 一把梭。
“经典”

coroutine

template strings

structured concurrency

Kotlin 真香

@sagaxu kotlin 的 when 快要被 java 的 switch 反超了
loom 明年出来，用起来感觉也会比 coroutine 更直观

java 究极体可能是 kotlin 或者 scala 这种（但是 java build 速度比这俩快多了）
语言特性还要看生态支持，比如 tomcat 之类的用 loom ，jackson 支持 valhalla 啥的
作为搬砖语言，j8 还能战很多年

loom 上了也不会切的，说实话绝大多数场景性能没差别，而且旧库都不支持，代码写起来很别扭，毕竟 java 的优势在于生态

@chendy 你看下上面，除了扩展函数，Kotlin 已经没有什么优势了，Scala 不了解

@micean loom 无足轻重，有没有都无所谓。valhalla 才是真正解决痛点的特性，让 java 能够逼近物理机的性能极限。

很多人觉得 loom 作用不大么..
loom 直接干掉了 现在的各种混乱的异步模型 /结构,继续用"同步的代码结构"写清晰的代码..忘掉什么回调,异步吧..
老代码一个连接一个线程的模式重获新生..并且也是最简单最直观的方式

Java 的究极体难道不是 C#吗

scala+1

@chendy tomcat 使用 loom 其实没啥用，业务还是 BIO😂，一样阻塞的底层的线程呀。我觉得协程较好的方案就是 async /await 语法糖，简单实现就好啦，它喵的就是不肯就范。
@ikas 是因为大家觉得 loom 出来后，很多生态都不会去改底层的东西。我倒不这样认为，因为我比较支持 vert.x ，别的生态改不改没啥关系，反正会有其他的生态去改。vert.x 支持 loom 应该会比较容易。