medium.com/graalvm/graalvm-for-jdk-21-is-here-ee01177dd12dps：不欢迎刷 jdk8 的梗

👍👍昨天白天看了好几次都没发版

希望 java 越来越好🥳

这玩意儿，大项目又一时不敢改，小项目又不咋关心性能，有点鸡肋，还是 jpackage 直接打包成 exe 务实一些。

国内有啥公司或者项目用 graal 吗 三四年之前刚出的时候就很多 但一直没见到落地的实践啊

小项目不在意性能，但在意启动时间，而且应用场景主要还是云原生吧。

貌似现在微服务化、容器化之后对于 JVM 的性能不怎么关注了。。。。

阿里云上大量 java 中间件都是用的 graal ，性能和启动速度提升很大。比如 mq ，polardb parser 等，发现 java 大厂都是优化狂魔。java 的野心很大，在霸占了业务开发之后下一个抢占的目标是 golang 的云原生，只是这个动作有点慢

这个跟 jpackage 还不太一样，这个是 native 了

大厂在乎啊，能省下好多机器而且能刷 kpi

我 graalvm 和 jpackage 都玩过，还是觉得大部分项目，jpackage 足矣(不用额外安装 jvm/鼠标一键使用)，graalvm 的部分库编译时屡屡不过，云原生的红利其实是给云平台的，跟最终用户关系不大。

native-image 对我们还是有用的，我们的很多内部维护工具、运维工具之类的，都编译成了 native 可执行文件，主打一个随用随丢，快速启动。而且语言是 Java ，所以大家直接上手，不需要再学 Go 之类的其他语言

我们是东 8 区时间。我们是 19 号，美国可能是 18 号的。

做云原生还是不适合 生态决定的

昨天夜里 YouTube 上可热闹了，半夜 12 点多看到 Java 在直播，GraalVM 也在直播，Spring 官方也在发视频，全在讲 Java 21

可以不编译 native ，当普通的 jdk 用，他的 jit 也有一定的优势

我没发现到处在用的例子呢，ali 有自己的 jdk ，因为之前 graalvm-ee 需要授权费，感觉大厂引入没那么快。

相比 graalvm ，我更看好 wasm 在云原生的前途； JDK21 的改变里，除了虚拟线程，我更喜欢"JEP 430 字符串模板（预览）":String name = "Joan";String info = STR."My name is {name}";

这个版本 native image 支持新 ffi api 虽然只有 downcall 但也不错了，gu 支持被移除改为在构建工具脚本里面声明对应组件，简直是重大利好新的 o3 优化等级从 spring petcline 测试来看和 graalvm ce jit 模式不相上下，还不错 medium.com/graalvm/graalvm-for-jdk-21-is-here-ee01177dd12d

native 要是能方便的解决反射问题就好了,之前做的 Java 客户端程序,使用 native 打包后内存占用降低了一个数量级,太强大了.

这个字符串模板语法太奇葩了

用的什么客户端库 swt swing 还是其他？

＃17 那个转义符看着好难受

为什么要用 STR. 这么长的字符？？直接像 Python 那样用单个字符会有什么问题？

STR. 模板处理器，是可以自定义的，比如 SQL. , JSON.Scala 就是这么玩的

还有 js 的 tagged templates

越短，冲突的情况就大，比如类名重复，误写，还会加大编译器的语法分析，长点的话，就比较保守安全。 我觉得 java 能走出第一步就很欣慰了，用着舒服不舒服慢慢进化。

用的是 awt 和 fx17 以及一些 fx 的 ui 库

高级，，那 STR. 可不可以自定义 S. 实现？？

＃26 同意 但是 API 都定义好了 以后要改只有再起一套

Android 刚用到 Java11还得是 Kotlin