dreamlike

不太懂 arm ，target 是 armv7 的产物，能跑在 8 和 9 上吗？如果是 8 能跑在另外两个上面吗

https://github.com/jbellis/jvector java 向量化搜索引擎
https://github.com/softwaremill/jox kt channel 的算法移植到 java 实现
https://github.com/gunnarmorling/1brc 1b 行数据处理比赛
https://github.com/eclipse-vertx/vert.x 响应式应用构建工具箱

void 不是类型导致的一系列泛型问题
举个例子 future<Void>, 说到泛型怎么能不提提经典的 function ，intfunction 呢？🤣
还有典中点只 arrays.sort 的各种重载
最后就是元编程能力，编译期 or 运行时元编程能力太弱 坐等 code reflection 实现，你可能说这跟我写 spring 有什么关系，请参考升级 jdk 但是不升级 spring 导致的 asm 版本问题 更何况 spring 自己依赖的 cglib 原始版本都没跟着版本兼容，还是 spring 自己魔改的，唉，要是 class file api 早点出来会有这事?
好特性出的太晚，远水解不了近渴
再吐槽下 openjdk group 对延迟到运行时 or 第一次使用时带来的冷启动问题，很多玩意本来就可以编译期搞定，结果一定要延迟到运行时，很多极其依赖于 jit ，说的就是你 lambda 和 switch!最后又得搞个 Leyden 擦屁股

👀我理解如果每个新 sb 项目都要这一套的话 是不是有个抽一个 starter 来自动配置呢？

@pursuit The execution state of the request has progressed far enough that cancelation is no longer possible ，不保证吧。。。

能请问下 io cancel 适配是卡在 io_uring 并不保证 cancel 成功吗？🤔我之前遇到的就是这个问题，在写场景/读场景 若未取消成功即操作已经推入内核执行的情况下 用户操作对应到那块内存就会产生 ub

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

virtual thread 目前 public 的 api 都太简单了，不如 kt 可以微操调度，所以我还搞了这个玩意 https://github.com/dreamlike-ocean/UnsafeVirtualThread ，来搞手操调度，指定调度器，捞 carrierThread
virtual thread 好处对我来说有两处:
1,是沟通 Reactive 到 Blocking 的桥梁，我可以低成本来复用老的 BIO 生态，比如我就喜欢开虚拟线程跑 jdbc+myabtis/hibernate,比 hibernate reactive 好用多了
2,我可以低成本将异步转同步，比如说 Future.await ，直接捞 continuation api 起来自己做调度也很好玩，对于 reactive 生态来说就无需引入 kotlin ，也无需被无栈协程的染色效应困扰

@furaoo 没做边界处理。。。设计个定界的协议吧 如果是能确定固定长度直接用 fixlength 的那个 codec ，如果没有报文中没有特殊符号也可以按特殊符号分割，或者直接做在头部放 body 长度的协议，不要依赖于裸的 channelread 行为