JDK 24 发布了

[Ayanokouji]

Features

404: Generational Shenandoah (Experimental)
450: Compact Object Headers (Experimental)
472: Prepare to Restrict the Use of JNI
475: Late Barrier Expansion for G1
478: Key Derivation Function API (Preview)
479: Remove the Windows 32-bit x86 Port
483: Ahead-of-Time Class Loading & Linking
484: Class-File API
485: Stream Gatherers
486: Permanently Disable the Security Manager
487: Scoped Values (Fourth Preview)
488: Primitive Types in Patterns, instanceof, and switch (Second Preview)
489: Vector API (Ninth Incubator)
490: ZGC: Remove the Non-Generational Mode
491: Synchronize Virtual Threads without Pinning
492: Flexible Constructor Bodies (Third Preview)
493: Linking Run-Time Images without JMODs
494: Module Import Declarations (Second Preview)
495: Simple Source Files and Instance Main Methods (Fourth Preview)
496: Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism
497: Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm
498: Warn upon Use of Memory-Access Methods in sun.misc.Unsafe
499: Structured Concurrency (Fourth Preview)
501: Deprecate the 32-bit x86 Port for Removal


https://openjdk.org/projects/jdk/24/

https://medium.com/graalvm/welcome-graalvm-for-jdk-24-7c829fe98ea1


此版本是非 lts 版本，今年 9 月份的 jdk 25 是 lts 版本


本帖不欢迎刷 jdk8 梗，都是 10 多年前的技术了，2014 年 3 月 18 日发布。

[cocong]

@Mark24 java 8 之后的版本开始收费，当然有开源版本，只是阉割了很多东西

[zhouhu]

@Greendays 很多 jvm 层面，比如 gc 的优化不深入的话是感觉不到。

[zhouhu]

@sagaxu compact header 值得关注，希望 Java 25 lts 能正式发布。

[sthwrong]

@darksheep9527 我的理解是虚拟线程和 goroutine 类似，虽然实现不一定一样，但本质都是为了轻量的并发。go 默认是不限制 goroutine 创建的，那么是否进行池化，只在于是否要限制资源的占用，当资源占用达到了要抢的程度的时候，是有可能比限制上限还要慢的。

[wupher]

目前新项目已经都是 17 了，希望能早日让我用 21

[Richared]

新启的项目都开始 21 了。现在 8,11,17,21 的都有。干活都快给自己干崩溃了。

[sagaxu]

@darksheep9527 Oracle 认为 JVM 虚拟线程不要用线程池。限流方法很多，使用线程池大可不必，实际 Go 的 Runtime 也会服用 goroutine 结构，同样也没必要池化。

Represent Every Concurrent Task as a Virtual Thread; Never Pool Virtual Threads
https://docs.oracle.com/en/java/javase/21/core/virtual-threads.html

@cocong 详细说说看，开源版本都阉割了啥？ Oracle 自己 build 也是从 openjdk 拉代码，再并入少量私有代码后构建。很多东西是指什么？

@zhouhu 25 lts 恐怕有点赶时间，紧凑头的改动还算比较大的，仅仅几个月的时间测试和观察，有点儿紧。

[msg7086]

@Mark24 8 支持期非常长（因为自己就在用，而且估摸着还得再用一段时间）。
7 已经过了支持期了，9 根本不是 lts ，11 间隔太长了而且升级没那么简单。
11 和 8 之间有个很大的沟，是 mockito 那些全部不兼容了，从 8 升到 11 意味着重构或者重写所有的测试用例。隔壁组前后花了一两个月才转换完一半的测试，另一半本来是我们组负责，但根本腾不出时间来做，所以现在只能把所有测试全禁了然后硬上 17 ，等以后想开了（或者想不开了）再回来捡。

[takanashisakura]

银行老项目 jdk8 ，谁敢动。今年新的项目倒是开始实验性使用 jdk17/21+springboot 了。

[seers]

我司还有 1.6 的在跑，虽然已经过了项目维护期，但是客户还在用

[javak]

我只想知道，springboot2.x 可以跑在 jdk25 上吗😅

现在在 21 上跑的很好。25 也能跑的很好，马上就升

[oneisall8955]

jdk17 准备下个月上生产

[spike0100]

@ccover 实际上不一定，只要能保证提高开发效率的同时还能保持稳定性， 不管管理还是开发都乐于尝试新事务。

[LowBi]

@Ayanokouji 啊？难道用了 docker ，生产环境就能随意切换 jdk 版本啦？怎么敢的啊？你的意思是随便切不会出问题是吗

[ccover]

@spike0100 #93 大多数是的，公司越大业务量越大，越不看重这个。管理、领导也是要担责的，他们关心的更多的是稳，至于新，并不能给领导层带来什么。领导会问用 JDK17 还是 24 能带来什么价值？什么？只有开发能用上能学到新东西吗？还有那么多不兼容的风险。

[ccover]

@spike0100 #93 我司之前就是用 1.7 、1.6 的，最近这一两年才把运行环境逐步改成 1.8 ，新项目也是要求只能用 1.8 ，问就是风险。
升级 JDK ，特别是 8 以前和 8 以后，有天壤之别，很多中间件都是不兼容 1.7 和 8 的。升级 JDK 到 8 意味着要把相关的中间件，框架全部升级一遍。
总结就是，JDK 升级能给领导带来什么？能给公司带来什么？如果只能给员工带来什么，那大概率不会同意升级。
就个人而言，我肯定喜欢用新的，毕竟没什么成本，还有新特性，开发起来也更舒服。

[Ayanokouji]

@LowBi 我的意思是你落后当前版本太多了，新项目还需要跟着服务器的 jdk 版本走？我们的项目 8/11/17/21 都有。

[gowk]

想知道切换到 Kotlin 难度和成本大不大，何必 stick with java 呢

[Ayanokouji]

@gowk
1. 原 java 项目切换到 kt 很难，不要说一个项目两种语言。
2. 要说服团队每个成员都使用 kt
3. 新项目用 kt

[LowBi]

@Ayanokouji 我的意思是项目还是原来的那个版本 你要是有新项目当然是新的 jdk 版本也行 可是逐渐变老的项目还是不能切版本啊 意义在哪 新项目可以试试新版本没问题 老项目还不是被吐槽落后版本不升级？