这是一个创建于 205 天前的主题，其中的信息可能已经有所发展或是发生改变。
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 ort
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 日发布。
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 ort
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 日发布。
106 条回复 2025-07-23 10:44:24 +08:00
 | 1 lujiaxing 205 天前  7 你发任你发, 我用 Java 8 |
 | 2 aptupdate 205 天前 via iPhone 我滴妈耶，都到 24 了啊？这是每年一个大版本的节奏吗？ |
 | 3 Ayanokouji OP @aptupdate 每年两个版本，两年一个 lts 版本 |
 | 4 iintothewind 205 天前 值类型真难产啊, Java 不得不带着镣铐跳舞. |
 | 5 ExplodingDragon 205 天前 不是 LTS 用不到，而且这一版没杀手级别的新特性 ... |
 | 6 wangtian2020 205 天前 什么时候支持动态类型了我再用 |
 | 7 letianqiu 205 天前 491: Synchronize Virtual Threads without Pinning 是这次最重要的更新了，virtual thread 总算是可以用了 |
 | 8 Goooooos 205 天前 等 9 月线上服务升级 25 lts |
 | 9 dragondove 205 天前 @ExplodingFKL aot linking 对于客户端软件算是很有用的功能了。compact object header 也是很有用的特性，虽然还是实验性的，现在也只合并了半个实现（ 8 字节对象头），4 字节版本合并到 lillput 上了，还在更新支持各类 gc 之类的。对象头的缩减对于服务端程序感觉能减少 10%以上的内存占用，还能够减少 gc 压力，对性能也会有提升。 |
 | 10 sleepyfevniv 205 天前 正在 21 + Spring Boot 3.x ，等发 25 lts 再换 |
 | 11 ovtfkw 205 天前 你强任你强, 我用 Java 8 |
 | 12 sagaxu 205 天前 |
 | 13 kzfile 205 天前 我也想用新的 jdk ，但是项目不允许 |
 | 14 liaohongxing 205 天前 Foreign Function Interface for Java (JEP 424) , 关于 FFI 的更新怎么没有看到消息 |
 | 15 Plutooo 205 天前 21 之前没关注过 jdk 版本的迭代，21 关注以后发现原来 jdk 的迭代这么快 |
| 16 Ayanokouji OP @liaohongxing https://openjdk.org/jeps/454 已经在 jdk 22 release 了 |
 | 17 5261 205 天前 你发布归你发布,公司项目 Java8, 任谁来都不好使~谁升级谁背锅 |
 | 18 Rever4433 205 天前 公司的项目还在 jdk8 -> jdk17 的迁移过程中 |
 | 19 wuyiccc 205 天前 还在用 jdk8+jdk17 两个版本并行中 |
 | 20 linquan 205 天前 不写 java ，之前写的还都是用的 jdk8 ，想问一下现在主流的版本是多少？是 17 么，vscode 的调试器貌似要求最低 17 ，感觉 jdk17 是不是和类似 cpp11 在 cpp 中的情况 |
 | 21 gitrebase 205 天前 结构化并发啥时候能转正啊… |
 | 22 wysnxzm 205 天前 有些人并没有意识到自己不追赶技术就会被技术追赶并淘汰的现实 |
 | 23 wwalkingg 205 天前 @ExplodingFKL 新的调用 Native 方法的特性很有吸引力啊 |
 | 24 daye 205 天前 不要再说“你强任你强, 我用 Java 8”，都什么时代了，至少 JDK11 以上，现在主流已经是 17 ，还在 Java8 的都是老古董项目了，还坚持你强任你强，只会被后浪拍死在沙滩上 |
| 25 daye 205 天前 @linquan 根据 2024 年的 New Relic 2024 Java 生态系统状态报告，Java 17 、11 和 8 的用户比例分别为 35%、33% 和 29%。 |
 | 26 LowBi 205 天前 java 啥时能做到 Windows 级别的向下兼容，那就真的没人再谈 jdk8 的梗了，目前跟着服务器 jdk 版本，服务器不升我不升 |
 | 27 spike0100 205 天前 刚给服务用上 17 ，多行文本和 switch 表达使用的美滋滋的。不知道怎么坚持 j8 用了这么多年的 |
 | 28 wetalk 205 天前 搞个投票，统计 V 站的朋友目前使用的 JDK 版本，以及对应项目的行业和大致流量，应该比较具有参考下  |
 | 30 yty2012g 205 天前 491 是真不错，终于更敢用 Virtual Thread 了 487 和 499 是不是计划 jdk25 release ？届时，下一代 Concurrency 模型应该是有一波显著的升级 |
 | 31 cheng6563 205 天前 Java 项目升级没那么难，只要你项目里没用那些意义不明的 sun 包的东西。 |
 | 33 cubecube 205 天前 1 谨慎升级 486: Permanently Disable the Security Manager 这个改动，兼容性问题很大，第三方库得修好一阵子才能搞定。 |
 | 34 ychost 205 天前 1 @wangtian2020 groovy 啥都支持，对于 CRUD 挺爽的 |
 | 35 BrookO 205 天前 我想问下,有没有人还用 java6 的 |
 | 36 Kamiyu0087 205 天前 我们公司都是 11 和 17 没有用 8 的 |
 | 37 NoKey 205 天前 这不老生常谈么，对于已经运营多年的老旧大型项目，基本准则就是能不动绝对不动，那不是 java8 是啥呢。。。。 |
 | 38 Niizuki 205 天前 我们老古董公司还在用 jdk8 ，醉了 |
 | 39 securityCoding 205 天前 @lujiaxing 我真的在用 java8 ，中国把 spark 版本钉死了 |
| 40 securityCoding 205 天前 @securityCoding 中国=》中台 |
 | 41 Rat3 205 天前 我还在用 21 ，性能很强，话说老讨论 java8 干啥，看多了也腻了 |
 | 43 TheWalkingDead 205 天前 via iPhone 招 java 的越来越少的 |
 | 44 yh7gdiaYW 205 天前 1 @daye 8 的真实比例比这个统计高的多得多，这个统计的是使用他们家线上监控的 Java 应用，可以预见的是国内不可能有少项目在用他们的服务，国内又恰恰是 8 的重灾区 |
 | 45 zong400 205 天前 zgc 稳定了吗？比 g1 好？ |
| 47 Ayanokouji OP @LowBi 但凡用个 docker ，也不至于根据服务器版本走 |
 | 48 Akitora 205 天前 491: Synchronize Virtual Threads without Pinning 好哇 |
 | 49 Yukineko 205 天前 491: Synchronize Virtual Threads without Pinning 我在 jdk21 上用虚拟线程，已经被这个坑了好几次了 |
| 51 Rat3 205 天前 1 @NoKey 问题大家在这讨论分享的是新 JDK 特性，大家都不是小白，谁不知道古早老项目一般不会动，但是在这种帖子反复强调 Java8 有啥意义，好比新能源车主聚会，大家讨论新平台，新的充电标准，冲进来了燃油车主说，你们聊归聊，我还是要开燃油车，我上班只能开燃油，话没错，说话的场景错了啊，朋友。 |
 | 53 zhouhu 205 天前 等 Java 25 |
 | 55 superchijinpeng 205 天前 现在大部分都是 17 了，不过 all in kt ，无所谓 |
 | 56 shen13176101 205 天前 用 8 就用 8 呗，不想升级背锅就不背锅呗，有些人非要来这里说一嘴显得自己高级么？ |
| 57 shen13176101 205 天前 @shen13176101 #56 之前公司也用 8 ，但是新项目直接用了 17. |
 | 59 bjfane PRO 个人项目或者公司内部平台已经用了 21 了。感觉良好，配合 springboot3.4.x |
 | 60 roundgis 205 天前 via Android @shen13176101 是用 java8 的人啥策。 |
 | 61 Rickkkkkkk 205 天前 不用新的 g1 不就是纯纯给自己添堵？ |
 | 62 jiazhutianxiadiy 205 天前 via Android 无知当炫耀的资本。小丑只是滑稽。刷 1.8 的只会更恶心 |
 | 63 irrigate2554 205 天前 公司项目用 1.8 不能换，自己项目不用 Java |
 | 64 adoal 205 天前 你气任你气，我用 Java 7 你逗任你逗，我用 Java 6 |
 | 65 DT27 205 天前 刚看了下我的工具箱： jre-8u91-windows-i586 jre-8u161-windows-i586 |
 | 66 reavid 205 天前 PS C:\Users\user> java --version openjdk 21.0.4 2024-07-16 LTS OpenJDK Runtime Environment (build 21.0.4+9-LTS) OpenJDK 64-Bit Server VM (build 21.0.4+9-LTS, mixed mode, sharing) |
 | 67 HENQIGUAI 205 天前 刚开始玩 21 ，还写了个脚本方便切换环境变量，坐等 9 月份的 25 |
 | 68 liudih 205 天前 我们就是 java8, 新项目也 java8 |
 | 70 JoeDH 205 天前 已经逐步升级到 17 了，8 不知不觉在淘汰 |
 | 71 111111111111 205 天前 在用 JDK17 |
 | 72 Greendays 205 天前 我倒是在用 21 的版本，但感觉好像也不太用得到什么特别的特性。 |
 | 73 salmon5 205 天前 逐步 JDK 17 已经很多项目在用，原生 G1GC 就是好 |
 | 74 des 205 天前 天啊 2014 都是 10 年前了，感觉过的好快 |
 | 75 darksheep9527 205 天前 @sleepybear1113 想问一下老哥,用虚拟线程的时候会不会用线程池,我当时实现的时候看虚拟线程思想是每次用就新建一个线程,线程池做的是 每次申请就新建一个. 但是后面发现 这样一来 大量请求进来都用到虚拟线程并发时,内存涨的飞快,但是这个业务可以接受慢一点,用有上限的线程池会更好, 但是奇怪用有上限的线程池后,prod 跑了一周似乎 hang 住了,又切回了了虚拟线程 |
 | 77 Gilfoyle26 205 天前 跟我一起读：三八二十四。 |
 | 79 Mark24 205 天前 为什么国内执着于 Java8 不是 Java7 也不是 Java9 ，Java8 有什么特殊性吗? |
| 80 Ayanokouji OP @Mark24 因为 jdk 9 太拖拉，而且是非 lts 版本，等到下一个 lts 版本 jdk11 ，黄花菜都凉了。 Java SE 8 2014-03-18 Java SE 9 2017-09-21 Java SE 11 2018-09-25 |
 | 84 sthwrong 205 天前 1 @darksheep9527 我的理解是虚拟线程和 goroutine 类似，虽然实现不一定一样，但本质都是为了轻量的并发。go 默认是不限制 goroutine 创建的，那么是否进行池化，只在于是否要限制资源的占用，当资源占用达到了要抢的程度的时候，是有可能比限制上限还要慢的。 |
 | 85 wupher 205 天前 目前新项目已经都是 17 了，希望能早日让我用 21 |
 | 86 Cruzz 205 天前 新启的项目都开始 21 了。现在 8,11,17,21 的都有。干活都快给自己干崩溃了。 |
| 87 sagaxu 205 天前 2 @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 恐怕有点赶时间，紧凑头的改动还算比较大的，仅仅几个月的时间测试和观察，有点儿紧。 |
 | 88 msg7086 204 天前 @Mark24 8 支持期非常长（因为自己就在用，而且估摸着还得再用一段时间）。 7 已经过了支持期了，9 根本不是 lts ，11 间隔太长了而且升级没那么简单。 11 和 8 之间有个很大的沟，是 mockito 那些全部不兼容了，从 8 升到 11 味着重构或者重写所有的测试用例。隔壁组前后花了一两个月才转换完一半的测试，另一半本来是我们组负责，但根本腾不出时间来做，所以现在只能把所有测试全禁了然后硬上 17 ，等以后想开了（或者想不开了）再回来捡。 |
 | 89 takanashisakura 204 天前 银行老项目 jdk8 ，谁敢动。今年新的项目倒是开始实验性使用 jdk17/21+springboot 了。 |
 | 90 seers 204 天前 via Android 我司还有 1.6 的在跑，虽然已经过了项目维护期，但是客户还在用 |
 | 91 javak 204 天前 via iPhone 我只想知道，springboot2.x 可以跑在 jdk25 上吗 现在在 21 上跑的很好。25 也能跑的很好，马上就升 |
 | 92 itechify PRO jdk17 准备下个月上生产 |
| 94 LowBi 204 天前 @Ayanokouji 啊？难道用了 docker ，生产环境就能随意切换 jdk 版本啦？怎么敢的啊？你的意思是随便切不会出问题是吗 |
 | 95 ccover 204 天前 @spike0100 #93 大多数是的，公司越大业务量越大，越不看重这个。管理、领导也是要担责的，他们关心的更多的是稳，至于新，并不能给领导层带来什么。领导会问用 JDK17 还是 24 能带来什么价值？什么？只有开发能用上能学到新东西吗？还有那么多不兼容的风险。 |
| 96 ccover 204 天前 @spike0100 #93 我司之前就是用 1.7 、1.6 的，最近这一两年才把运行环境逐步改成 1.8 ，新项目也是要求只能用 1.8 ，问就是风险。 升级 JDK ，特别是 8 以前和 8 以后，有天壤之别，很多中间件都是不兼容 1.7 和 8 的。升级 JDK 到 8 意味着要把相关的中间件，框架全部升级一遍。 总结就是，JDK 升级能给领导带来什么？能给公司带来什么？如果只能给员工带来什么，那大概率不会同意升级。 就个人而言，我肯定喜欢用新的，毕竟没什么成本，还有新特性，开发起来也更舒服。 |
| 97 Ayanokouji OP @LowBi 我的意思是你落后当前版本太多了，新项目还需要跟着服务器的 jdk 版本走？我们的项目 8/11/17/21 都有。 |
 | 98 gowk 204 天前 想知道切换到 Kotlin 难度和成本大不大，何必 stick with java 呢 |
| 99 Ayanokouji OP |
| 100 LowBi 204 天前 @Ayanokouji 我的意思是项目还是原来的那个版本 你要是有新项目当然是新的 jdk 版本也行 可是逐渐变老的项目还是不能切版本啊 意义在哪 新项目可以试试新版本没问题 老项目还不是被吐槽落后版本不升级？ |
Select Language