GraalVM for JDK 21 发布了

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

希望 java 越来越好

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@cubecube
@kuituosi
相比 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 模式不相上下，还不错
https://medium.com/graalvm/graalvm-for-jdk-21-is-here-ee01177dd12d

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

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

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

@wangxiaodong #17 那个转义符看着好难受

@wangxiaodong

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

@XIVN1987 STR. 模板处理器，是可以自定义的，比如 SQL. , JSON.

Scala 就是这么玩的

@Leviathann 还有 js 的 tagged templates

@XIVN1987 越短，冲突的情况就大，比如类名重复，误写，还会加大编译器的语法分析，长点的话，就比较保守安全。


@kid1412621 我觉得 java 能走出第一步就很欣慰了，用着舒服不舒服慢慢进化。

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

@Leviathann

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

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

Android 刚用到 Java11
还得是 Kotlin

关注启动速度和内存占用的可以了解下蚂蚁集团开源的 koupleless.io 啊，可以让存量应用 10 倍提升的框架