在写之前首先说明，java的冗长一般是两方面造成的。
- 1 是他语言本身，这个是本文要说的，在最近几年的一系列版本更新中已经改善了不少，这也是本文要说的。
- 2 是用法相关，古早的框架需要写一堆模板代码，臭名昭著的写个service还要先写个IService，接口一大堆。但这是古早框架相关，这也导致很多新手接手公司旧项目就被糊一脸，历史屎堆噩梦了属于是。现代的sb之类可以很简化，这个就不在本文讨论范围内了。
语言本身，java平台的各类其他语言，比如scala，kotlin等都比java语法简洁，近几年的java也在吃进一些他们的语法/概念，java总体还是更往函数式上走的。
record
java的POJO之前写起来太麻烦了，getter，setter还要覆盖hashCode equals等。
很早lombok的@Data就能简化，java也引入了record再进一步。（不过record不可变，不一定所有场景都满足）
之前的POJO：
现在的写法：
有些场景需要在方法里定义一些临时用来运算的结构，之前偷懒不想定义一个class可能就用Map放了，类型不安全加很冗长，后面函数式的库起来了比如Jool/vavr，可以用tuple放临时结构。
java的record也可以临时定义。
之前：
临时定义record：
模式匹配
这东西是新语言标配了，最近的语言都有这个，表达力max，java也一样引入了，但是java的结构能力肯定是没法和其他一些语言比的，这个特性还在不断迭代。
对比
老的写法：
新的：
因为java之前不带sum类型，在模式匹配里无法使用编译器检查所有情况，所以后面出了个比较难看的密封类。（相较于其他语言可以直接用case或者|等语法定义）。但是好歹还是有sum类型了不是吗。
和其他的比是真的挺丑的。。
（注意 ts默认的是union type（也就是无标签） 这里给他写了个kind来模拟sum type）
连续（级联）空判断
其实就是引入了Optional这个类，语法上没变化，主要是API。
之前：
现在：
这个optional其实设计有问题。。。
map感觉设计错了 众所周知map是用来 O(x) → O(y)的 map里如果返回null应该是Optional.value(null) 他直接变成了Optional.empty(这个工作应该交给flatMap才对）
让AI来解释下：
不可变集合创建优化
这个同样是API层面，但是写起来就舒畅好多了。
新的：
字符串模板
这东西真是奇了怪了。。。现在还是个预览特性，需要打开开关才能用。
基本是新语言标配功能。没有之前用的apache lang包下的strsubstitutor,也能简化拼接。
（text block本身早就release了）
虚拟线程 结构化并发
这个解决了java一直以来的本地线程开销大（主要是内存开销 以及大量唤醒时的切换开销），之前重IO任务，你要么精心设计线程池，要么混合用reactive（这个会污染API），写起来都不那么顺手。
其他新语言倾向于async/await来简化，但是java直接在虚拟机层面引入虚拟线程，在不改变语法情况下实现重IO任务的优化。
让AI总结下：
（当然要更高性能还是得上reactive混搭）
（CPU密集任务还是推荐本地线程跑，这个和async/await一个道理，没法yield了）
结构化并发更是将之前的多线程任务可以以更可控的方式实现，但是这特性还是preview。。。还不能直接用。
其他还有零零散散的。
但是趋势是java不断向kotlin和scala等JVM平台的其他语言靠近。
所以说java语法冗长，在最近的版本里其实已经改进很多了，当然焊死java8的话…就挺难了（建议把jool/vavr引入 多吃点函数式，虽然这俩东西也很久没更新了） 
21 个帖子 - 12 位参与者