JDK 14 发布了

距离下一个 LTS 的 17 还有一年半时间
感觉 loom 这种依然遥遥无期…

Java8 路过。。。现在学习 Java8 太合适了，资料多，而且企业大部分都是 8，甚至有些是 6

还是 kotlin 好

重新下载一遍 OpenJDK，发现和半个月前下载的文件一样。应该是早就准备好发布了，之前就奇怪，Java version 打印出来的日期是 3 月 17 号。

AdoptOpenJDK 14 还没发布正式版本。

Preview 这种方式挺好的，没正式发布之前，先得到用户反馈，不断改进。总之一下出来的标准好。

切换 JDK，用 Maven 的 Tool Chain 就好了。

Text Block，Record （ Kotlin Data Class Clone ），Pattern Marching （现在还不是很好用，功能不如 Scala 强大）现在 Java 14 都有了。Sealed Class 也在加入之中。这对提高开发效率还是不错的。

小步快跑可比瀑布模式好多了,发现有问题及时改正还来得及

@hantsy
@wysnylc 问题是 preview 的 feature 万一后面的版本改了，甚至删了。。你的代码怎么办，就被锁定版本了。或者出个转换工具，类似 js 的 babel。。现在还是 kotlin 稳，把 JVM 作为 runtime，语言特性不跟特定版本绑定。不用担心后续兼容性。

半年一个版本谁敢用

@sagaxu 前端一个月一个版本也没见谁不敢用啊?

C# 欢迎各位

Instanceof Pattern Matching
https://github.com/hantsy/java-sandbox/blob/master/docs/instanceof-pattern-matching.md

Helpful NPE Exception Messages
https://github.com/hantsy/java-sandbox/blob/master/docs/helpful-npe.md

Record
https://github.com/hantsy/java-sandbox/blob/master/docs/record.md

Small improvements in Text Block
https://github.com/hantsy/java-sandbox/blob/master/docs/java14-text-block-improvement.md

14 了？感觉 8 以后完全没有更新的可能了

@gz911122 前端很少设计业务逻辑，后端往往和业务逻辑数据库挂钩，想对比起来同样更新频度，后端风险更高

@sagaxu Spring 5.3 兼容 14 了。一些新语言特性也在支持中，看到有 Experiemental 项目尝试支持 Record （肯定要等 Record 稳定后才可能出现在 Spring 正式版本中）。

之前团队从 Java8 升级到 Java11 过，收益并不大，迁移成本还不小。后续升级应该会谨慎很多。。。

@tulongtou 并不觉得,
我就是 java 后端,就是 java 领域持续已久的懒惰,连个 maven 依赖都不跟随升级,还指望升级 java 大版本..
(又不是不能用

真是养老最佳选择

好奇问下，jdk 历史上有 breaking change 吗？

NPE 改进挺重要的
record 在 lombok 的加持下有些鸡肋……

@keshawnvan 8-11 不知道会有什么成本？难道你全部用 Module System ？
收益方面嘛，11 后我用得多的几个语言特性：
var,
Collections 的 .of 静态工厂
另外，Optional，Stream 等也在 8 后加入一些实用方法。

8 还能用一万年

现在还用 jdk8，之前从 jdk6 升级上来的，真香。。

@hantsy 我们之前的项目有兼容旧系统的一些接口，升级 11 之后 JavaEE 的东西都干掉了，兼容花了很长时间。11 在语法层面的提升比较小，用的比较多的就是 List.of()和 Map.of()。var 很少用，什么时候 Java 能出个 val。。。

很多在运营手游服务端后端还在用 jdk6

@yiyi11 都是一些 api 的增增减减，大的 break change 没有，java 很重视兼容性

@chendy 之前准备弄 2 套, 一套原来的现成, 一套可以无缝切换的协程, 现在又特么改了. 直接替换线程实现协程了貌似. 遥遥无期.

还好吧，14 那个 switch 真的很像 kotlin 的 when 了，这个语法比之前那些香多了，再也不用 if..if else..if else........

公司用的 8

等 jdk20 再说

头像很漂亮，哦哦，你说的是 JDK 14 呀

我们公司还在用 8 呀...

@sagaxu golang 发版也挺快的啊。

就算出了 JDK 10086，我还是坚持 1.8

这是面向 KPI 更新吗？

好多 kotlin 的特性 java 也有了。。

@chendy java20 应该就有了

8 很好，先这样吧

@jinsongzhao 看头像 哈哈哈

管他咋更新, 我脚的公司就会一直用 8.....

.net 5 preview 1 也出来了

坚持 java8 不动摇

loom 还没出 没啥质的改变 8 够用了

下次一定，我还是用 8

@keshawnvan 迁移的成本体现在哪些方面？

java8 对企业来说还是免费的，后面就要收费了，除非用的不是 oracle 家

现在来说，8 确实已经够用了，后面的更新都是不痛不痒的，大家都不怎么关注。
估计下个大发布，就是 Loom 了。

@zichen 泛型支持了没？

@zichen 我的关注点是 preview 的 feature，没有一个兼容的机制，preview 的后来被删了就尴尬了，我觉得大家是不敢用的。Go 也是 6 个月一个版本，但是会兼容的； Java 以前也是兼容著称的，现在改成这种发布，真没觉得好。

@keshawnvan Java EE 部分主要是 JDBC,XML,Web Service 的为了写 Client 程序的一些 API，早就计划删除，这些只要重要加回依赖就好了。

@rockyou12 Switch Expression 经过三个版本的迭代现在 Stable 了。

升级的需求是啥？拼命更新，老系统都吃不消吧

实际从 8 后面，JVM 的变化非常大，GC 算法增删很大，这些不是做这些领域的工作，没怎么关心。

@ZSeptember Kotlin 的语言特性也是采用这种机预览机制添加的。

我就想问默认参数什么时候支持啊？复杂一点的类，本来一个构造函数就能搞定的事情，现在要要一二三四五，甚至六七八个构造函数，累不累啊？

@yiyi11 几乎每个大版本都有 breaking change，只不过可能大多数人用不到那个角落的功能

@FrankD 只针对订阅用户收费。Oracle 对开源贡献很大，是值得尊敬的公司。

@sorra 有些标准化， 比如 Base64 Encoder。

很少量的删除了，一般都是有替代品。一个主要我看到就是清理以前 com.sun 里面的 API，这里面有很多写工具，操作 Class 文件可能用到的 API。除非大势已去的，比如 Applet，直接 Cut 掉了。

另外一个 Java 11 中 Stable 的特性是 HttpClient，我觉得算是一大特性，它基于新的 Java9 Flow API 和 8 的 Future API。

试用过，感觉有点点怪怪的。写什么客户的时候不需要再用第三方 Http Client，如 Apache,OKHttp 等。

处理一般的文件，InputStream，String 的数据都是可以的，JSON 可以借标准 JSONB，JSONP 等。

java14 出来后跟 kotlin 好像。

Kotlin 现在 Spring 是全盘接受，Kotlin 确是一等公民，所有特性都是急于添加 Kotlin DSL 支持。Kotlin DSL 语法是好是坏，我个人没太多感觉。

虽然 Spring 以前也接受过 Groovy，Scala。Groovy 进入了 Spring 核心，坐了冷板凳。Scala 还未进入核心，直接放弃了。

Kotlin 感觉强大的两个东西，extensions, reified，很多 Spring 的 Kotlin API 简化支持都是在 Reified 语法上做文章。

移除了 CMS 垃圾收集器，ZGC 也支持 Mac 和 Win 了

@yiyi11 之前 8 有个小版本引入了 keystore 相关的安全性增强，然后很多应用就挂了，需要 workaround 才能正常工作。7 升 8 的时候计算的 rounding 改过，8 升 11 的时候 locale 相关也改过。这只是我碰过的。

CMS 是不是已经删除了？

需要用到 Nashorn Javascript 引擎，9 以后就 Deprecated 了。比较关心多个 jar 包运行时，是否真共享 jvm，节省内存了。

@jinsongzhao 已经删除了 JS Engine。

@hantsy Oracle 这公司已经算是业界毒瘤了吧，口碑比当年的微软还差。
你仔细看看协议，Oracle 发布的 JDK 是每个版本只维护半年，半年后是没有免费更新的，哪怕 LTS 都是一样。你想用那就要么跟着半年更新一个大版本，要么就买服务。订阅服务是可以获取长期更新的。
不然为什么大厂都发布自己的 build，就是因为原来用的好好 Oracle JDK 没法用了。

skip this version +10086

@hantsy 依赖没那么好加，很多给出的依赖都不好用。。依赖在运行时不兼容的问题也很多

要看 LTS 版本，这种普通版本无所谓了…跟 go 不一样，go 的随便升级的

还在使用 java1.6.

@FrankD 然而事实是只有截止 JDK8_u202 是使用的旧的协议， 之后的 JDK8 版本协议也换成最新的那版不支持免费商用的版本了。
也就说说从 19 年 3 月之后在 oracle 官方下载的最新版本 jdk8 用于商用的话都是违反协议的。
想免费商用那只能当 JDK8 也结束维护周期了，只能注册一个账号然后去它的 release 存档里找 u202 之前的版本。


(不过我身边还是没有见到有谁提这茬事，还是依旧去下最新的 jdk8 继续用)

@jinsongzhao
nashorn 可以转 graaljs，graaljs 提供了 nashorn 兼容模式，加两个 jar 依赖即可
https://github.com/graalvm/graaljs/blob/master/docs/user/NashornMigrationGuide.md

java8 能战 10 年

@hantsy Oracle jdk 的新协议是对任何商用都收费，和订阅不订阅没关系。Oracle 官网提供的 jdk 和 openjdk 官网提供的 jdk 是两份东西，包含的私有技术和使用的协议都不同。openJdk 的协议才是用的原来的可免费商用的协议。

Oracle 确实对开源贡献很大，一方面他们确实将自己的部分内部技术拿来提升了开源项目，另一方面他们也买黄了好几个开源项目。

Kubernates 每个季度都会发布一个版本，有许多 API 接口都是不稳定的 alpha 版，这个并不会影响用户实际使用，未到生产可用的 API 不使用就完了。

@chendy 前不久刚发布了第二个早期可用版本，Java 版的协程以后可能会叫”虚拟线程“了

14 看了遍新特性，
npe 的调整还是可以，
gc 相关的改动很多，
cms gc 在 14 退役了，
不过生产还是 Java 8。升级收益点不是很清晰

@hantsy kotlin，确实是的，但是 kotlin 是没有绑定 JVM 的，升级降级会简单一些。

Java 8 - 14 的变化 ：

https://ondro.inginea.eu/index.php/new-features-between-java-8-and-java-14/

昨天头一回用那个 mybatis 写了个 select，run 的时候报错代码 5，噢，原来是要用 jdk8，真香

什么时候支持纤程

@wysnylc 谁敢用？。。。自己学着玩还差不多。

我觉得近几年更到 11 有希望，14 估计还要等个七八年吧

8 都没摸透. 11 就更没去看了

Kotlin 什么都好，就是那个异常不能强制抛出了，现在的业务异常严重依赖 Exception。

吓得我赶紧抱紧我的 Java 8

升级 jdk 版本对 kpi 没用，出锅了还要背锅

@0xljh +1 而且这种坑填起来很费劲

java 出到 100 了还是大多数用 8

我选 scala

@ben1024 更新个 var 也不错嘛，虽然在 idea 上我还是尽量避免用 var 的，不能像 vs code 一样把鼠标放上去自动显示实际类型。

不是 LTS 谁用啊。。
Record 字段多没法写注释太 sb 了，被 lombok 吊着打
JDK11 也没啥动力更新，说实在 lombok 的 var 和 val 已经够用了。。再说想吃语法糖不如 kotlin

我司定格在 jdk-8u181 这个版本了, 原因也很简单粗暴: CDH 官方认证, 然后集群统一 jdk 版本利于运维.

https://docs.cloudera.com/documentation/enterprise/6/release-notes/topics/rg_java_requirements.html#concept_hzw_zyl_rcb

https://docs.cloudera.com/documentation/enterprise/release-notes/topics/rn_consolidated_pcm.html#concept_ihg_vf4_j1b

贴错了, 因为 CDH6 吃相不太好看, 恰好运维也不想升级折腾, 所以 CDH 5.16.x 是在用版本.

jdk14 可以到这里来下载 http://www.jdkdownload.com/