JDK17 都出来了，感觉现在很多资深程序员 Stream 不会， Lambda 不会， Java .time 包不会

[qwerthhusn]

不少资深人士写代码的时候还是各种 for 循环。

Lambda 也不用，还用各种匿名内部类。

还有 JDK8 的时期时间库，很多人还是在用 Date ，Calender 。现在的 LocalDate, LocalDateTime, YearMonth, ZonedDateTime 做时间计算真的特别直观简单，但是他们就喜欢用 Date ，简单的计算就用毫秒加减，复杂点的计算就先换成 Calender ，完事后再转换回 Date 。

甚至 JDK7 的 try-with-resources 语法我都感觉不少人都不知道。

所以，现在“JDK8 是主流”这句话是不对的，而是“JVM8 是主流”才是对的。语法的主流应该是 J2SE 1.5 。

很多人说“会这个能咋样，能写出 NB 代码吗？工资会变高吗？”
当然不会，但是学会并使用这些功能，在某些或者大部分场景下，能让代码更简洁。
简洁的意思就是代码敲的更快，代码量更少，缩进或者嵌套更少，能更快的解决问题。
更快的意思是，能有更多的时间搞别的事情，比如摸鱼！

[wxlwsy]

用 java8 几年多了,用 time 包的次数只有当初学习的时候写过几句,实际上时间操作都是现成的基于旧 api 的工具类,几乎没有重新写个 time 的工具的需求啊.

[nothingistrue]

很多人不会，不代表不主流。JVM8 也不是主流，不管是 Eclipse 还是 Idea ，老早就强制升级 JVM 了，所以至少 IDE 端，已经早就不在 JVM 8 跑了。

[nothingistrue]

Spring 6 / Spring Boot 3 要以 JDK 17 为基准版本了，这回 JDK 8 终于要到头了。

[Cmdhelp]

会了能怎么样

[lululau]

某些资深程序员会说，用 stream API 写的代码可读性太差 😂

[chendy]

不会也不耽误啥，人家写代码就是个工作，能实现业务需求就行，没有什么别的追求
再说 Java8 时间 api 都是不可变对象，让他们用也未必能用明白不是么……

除非公司或者团队有这方面的要求，否则就做好自己就好，别人怎么样就怎么样吧

[jaoyina]

为什么呢？

[Leviathann]

SpringBoot2 的非商业维护时间好像不会很长

[bytesmith]

太正常了，自己尽量用就行，别人感觉管不了- -

[cheng6563]

java.time 并没有 DateUtils 或者 joda-time 好用

[hidemyself]

我都会，但是不妨碍我最低的职级，最少的工资

[statumer]

有没有一种可能，for 循环对 JIT 编译器来说更好优化，更好调试，更好维护？而 Java stream API 主要是满足一些函数式爱好者对 List monad 的热爱？

[marcong95]

迫于并不主要用 Java ，偶然用一用 Java 的时候 Stream API 总想不起来。还是 JS 、Python 、LINQ 的比较愉快~~

[zhangchongjie]

@statumer 满足其他语法来学 java 的装逼心理，现在各种语法糖 。找错，调试都比较麻烦

[pengtdyd]

35 岁淘汰就搁着来的

[yeyang5211]

@lululau 哈哈 我就这么说, 后来会 steamAPI 之后就想着管你谁来维护 我先写这爽再说

[besscroft]

我都会，但不妨碍我工资低还没人要。

[MoYi123]

不会 java, 学习 stream 难度很高吗? 为什么很多 javaer 以自己会 stream 为荣?

[Leviathann]

@MoYi123 因为还有很多真的不会还喜欢找理由
另外 collect 的部分复杂起来的确有些麻烦，这是 api 设计的问题

[string2020]

一个臭做工程的天天嚷嚷自己的工具如何先进是闹哪样

[Kiske]

我表示同意, 而且这样的员工比各位想象中还多, 甚至我自己就是,对 JDK8 以上的特性一概不用,

个人角度来看, 这算是学习知识上的停滞, 函数式 声明式编程好用, 但没那能力用.

生态环境上, 各位认为现在跑着的 JDK 1.5-1.7 的项目到底还有多少, 我认为在很多看不见的地方, 无法被统计的地方,还有大量的老旧系统, 这样的项目太多,直接导致外界很多人对整个 Java 生态圈产生了腐朽,臃肿.效率低的印象.

[vfs]

如果以会不会编程语言的高级特性来判断一个程序员的水平，那未免有些草率啊。 我称得上是老古董了，从来不适用高级特性，就是使用最简单的 while ，for ，if. 因此，我无论 写 java ，还是 c++，感觉都一样。

[0x663]

是，到现在我都不会茴字的四种写法

[nothingistrue]

@Cmdhelp #4 Lambda 就会让你多一份技能，而 Stream API ，会引导你走向流式数据处理的大门——艺多不压身。
@statumer #12 当数据量级小的时候二者没区别，当数据量级上去之后，stream API 对性能更好。

抛弃上面的不说，Stream API 在编码友好性（主要是链式操作），跟可读性上（ Java 8 的还因为 API 不完善导致由局限，9 、10 之后就差不多完善了）都有很大的提升。OP 的观点只是略有不妥，而上面有些人，那是不学无术还要瞎叫。

[tulongtou]

什么都不会，凭什么被称作资深人士？

[Akitora]

time 包真心好用

[siweipancc]

良好的代码设计才是关键，一大堆循环，递归，无用的大量实例创建，用 jdk17 都救不来。

但是高版本的编译器有更好的优化又是个事实，op 不过是太激进了。
我负责的项目升到 13 又降回来 8 ，第三方库不支持，全是泪，幸好升级那会只用了几个特性

[lujiaosama]

真正的老玩具都是各种语法糖用得飞起的, 代码简练高效, 新手读起来有门槛但是读懂了就能感受到优雅. 哪天 review 看不懂刚毕业出来的新人写的代码那就闹大笑话了. 而且写习惯了声明式之后回头看命令式代码真的感觉又臭又长.

[pocketz]

java.time 真的很好用。。。

[zmal]

日经贴，会不会 stream 不能作为代码水平的判断工具，用 stream 写烂代码的人比比皆是。建议上 code 。

[leaves615]

能解决问题的代码都是好代码。

[Suddoo]

是啊、所以、这些所谓的“资深”程序员也就那么回事儿而已

都 Java18 了、很多东西早变了、JDK 也加入了大量新特性，但是“资深”程序员还是会用自己过时的经验来考新人：
new String 创建了几个对象
JVM 如何“调优”
手写几个设计模式
……

写代码的时候还是又臭又长的旧 API ，一行代码就能读取文件，非要几十行写完，显得自己严谨，问就是要懂“底层”

lambda 不用，还是一堆匿名内部类，问就是语法糖、没意义、“底层”重要，lambda 都特么 10 年前的玩意儿了

[hs444]

stream 和 lambda 一开始只是了解，工作中也不用，后来开始用 idea 之后活生生被 idea 教会了。
时间相关的操作都是直接用外部工具类。
try-with-resources 确实方便，一直在用。

[hhjswf]

localdatetime 相比 date 好在哪

[coetzee]

@hhjswf 这种问题搜一下不就知道了吗？

[coetzee]

对于大部分 Java 的人，被人家别的语言骂我觉得是没毛病的，你命名 Java17 可以做到很大简洁性提升，但是非要沿用老的一套，你问问他，裹脚布香不香？理由和借口贼多，其实都是放弃学习、放弃进步的表现，大部分面试只要问到八股文的，不用考虑是技术型工作，就是写业务，而且技术老旧

[ql562482472]

stream 不会、java.time 不会的，确实很讨厌，简单逻辑往往写一大堆 最后一看新 API 一句话就讲明白的事情

[levon]

stream 做循环确实代码比较丑

[Huelse]

@statumer #12 事实上全部使用基本语法并不代表着维护性更好，程序员们绝大多数优化都是为了优化而优化

[gabon]

stream api 可读性更高

[sampeng]

@nothingistrue

当数据量级小的时候二者没区别，当数据量级上去之后，stream API 对性能更好。

这个问题是你自己做的测试得来的，还是网上说的？

[sampeng]

说 stream api 可读性更高的是熟悉 stream api 的可读性更高。不熟悉的就是看天书。
for while 怎么了。。这还能有原罪了？

[zhuangzhuang1988]

会又能咋样，能写个类似 lucene 么，或者 h2 么 这些可是在 jdk8 之前就出来了

[zhuangzhuang1988]

@sampeng 对的<effective java>上就有讨论，
第 45 条：谨慎使用 Stream 159
第 46 条：优先选择 Stream 中无副作用的函数 164
第 47 条：Stream 要优先用 Collection 作为返回类型 168
第 48 条：谨慎使用 Stream 并行 172

有的时候 stream 写出来的真是天书
https://book.douban.com/subject/30412517/

[dcsuibian]

1 、Lambda 是肯定要用的，要不然多麻烦
2 、时间的我也喜欢用时间戳计算然后转成 Instant （时间段长度固定，与时区无关的情况下）。其它几个用的比较少，数据库里存的和返回给前端的都是毫秒时间戳，交给前端去格式化。但 Date 、Calendar 肯定不用。
3 、try-with-resources 会用，但用的不多。因为如果你调用的方法会抛出检查型异常的话，那么放在开头的括号里的很麻烦。（我倾向于方法生命无 throws ）
4 、stream api 用的挺多的，但 for 也在用。
因为 stream 中间有个函数会抛出检查型异常的话，处理也比较麻烦，不优雅。或者只是 steam api 用得太多了。

只考虑 LTS 版 Java ，现在开新项目已经可以直接上 Java 11 了。
那乐观估计，2025 年至少得开始学 Java 17 了。

顺便问一下，学新版本是只看新的部分还是直接重学当复习比较好呢？

[wfd0807]

说 stream 可读性高应该是用于简单场景，数据逻辑复杂聚合操作，代码格式化都是个问题，就不用说可读性
stream 可以简化一些简单的循环、归集操作，真没有必要上纲上线
如何能用最快的方式达到目的才是值得关注的问题

[lixintcwdsg]

主要这些细节提升不了多少生产力。
一般来说一个项目，编码可能就占 15%，大头在前期预研，项目价值，架构设计，项目管理沟通等等上面（大公司）
编码一些新特性生产力提高 15%，对于整个项目就是 2.25%的提高

[kett]

你觉得是那就是吧

[adoal]

也许人家在 stream 流行之前就已经修齐治平迎娶白富美了

[lawler]

年轻人没有写过复杂功能时的意淫罢了了，就像 c 看不上 java 一样，c 在尽善尽美。

之所尽可能的减少使用 stream 是因为某一天，我需要从一个 list 中计算多个维度的数据。
我发现循环过滤分组再过滤取属性计算 sum/avg/cont 后代码很屎。
从此，凡是需要 stream 处理时，我会优先考虑我需要几个 stream 。超过两次就直接 for 了。

至于 lambda ，再设计了大量单一方法的接口后，发现也很鸡肋。只是为了使用 lambda 而设计，但却定义了大量的单接口方法，一单出现补充接口方法，就有各种问题。从此只在 jdk 中使用，不再在自己定义可以使用 lambda 的接口。


不可避免的，当涉及复杂系统应用的时候，这些语法糖没有任何意义。
你看 spring 源码，有大范围在使用这些特性么？

[wenbinwu]

别纠结语言框架，这东西只有熟练不熟练的问题
基础懂了，随便换，就是个看文档的问题

如果一个人说我一天写 10 个小时代码，那他写的代码肯定是烂的
把自己想成工程师，而不是码农，把时间花在思考上，而不是写代码上

[securityCoding]

这几个类库不会确实有点离谱了

[ddonano]

jdk 11 和 17 有啥新特性，只会用 jdk8

[ElegantOfKing]

我专门学过这些东西，项目中也多多少少会用到相关的特性。
但是，但是哈，一旦遇到复杂的逻辑，我就大概率不用，或者用了，但是做很多注释。
实在是有些特性太抽象，对于后面维护的人来说，是个累赘。

[felixcode]

新版本新功能绝对是不稳定的，刚参加工作那段时间的软件和版本都是最稳定的，年轻人不要一味的追求时髦，新功能一般都是没用的。
狗头；）

[dongcxcx]

这个并不是什么大不了的东西,项目里如果有的话直接就用了,没有看一下也很快就会了.

所以这个不会能咋的,会了又能咋的.

[nutting]

那些风格的代码看不惯，不像 java

[zpxshl]

你一天的时间有多少在编码的，少写几行代码真能让你更摸鱼吗。
反正我编码时间不到 1/10

[aliveyang]

只在简单场景用过 stream

[xiaowangge]

据说，蚂蚁金服某组是禁止使用 Lambda 的

[Rocketer]

作为一个做过 C#的程序员，我很习惯 stream 但很不喜欢 java 的 stream 。那语法比 linq 实在是难读难记很多。

[Goooooos]

资深=会各种新潮 api??

[dqzcwxb]

Completablefuture 还有好多连名字都不知道的

[aguesuka]

这栋楼完美诠释了为什么 Java 程序员拥有刻板, 啰嗦, 不思进取又菜的刻板印象.

[dqzcwxb]

@aguesuka #64 这样的人 35 岁被淘汰也不稀奇了,拒绝进步拒绝新技术那么被行业抛弃再正常不过

[icyalala]

学新东西是好事，这没问题。但实际表现并不是 "学了新东西就能开发得更快"。

是你要知道，学习也是有学习成本的。对于已经熟悉的 API 来说，使用者有"路径依赖"。就是说，即使达成一个目的的路径相对更长，但是因为使用者熟悉，他反而能更快达成目的。

[TWorldIsNButThis]

推新 api 新语法已经是比较温和且进步的了
激进且保守的直接用 go 垒💩山，不跟你 java 这帮遗老遗少玩了
你喜欢过程式老语法？我 tm 大道至简，连 class 、泛型都不想要，加了泛型就变味了，来嘛，比谁语法更少。

[ca1123]

管用就行, 能拔脓就是好膏药. 比如我就写不来 C 这一绺子的代码, 只能写函数式...

[dannyzjwz]

http://16.162.252.129:81/#/ 交易所找人 wx 17795098941

[dannyzjwz]

@dannyzjwz 交易所找后端开发，需要熟悉，orderbook, 交易撮合引擎

[silvernoo]

我全都不会，但是会耽误我继续保持高收入吗？

[Suddoo]

资本家也挺为难的，知道这些“资深”p 几真的就是个 p 了，把他们作为人才输送给社会的时候，这帮人还叫得贼厉害

[frankies]

你 20 多岁年轻追求新 api 彰显生产力没毛病，请不要用这个来作为指责码农的工具。我是 30 多的临近职场生命末期的大叔了，何尝对 coding 没有过热爱和追求，不过见过太多追求框架熟练工的年轻人之后，发现做好工具人就好了，永远记住你学的不是技术，而是技能，一个手艺活罢了。

[cassyfar]

资深程序员，表示不会 stream ，不写 lambda ，Java.time 也没用过。是不是要被优化了？

[jjwjiang]

Java 的 stream 不用也罢，根本起不到和 C#一样的从便利性、可读性上有飞跃提升的效果
根本原因是 Java 的类型设计就很差，没有 IEnumerable 这样的基础，让 stream 做不出管道式的效果，任何操作之后都得 collect 创建新对象

至于在这贬低 lambda 本身的就很搞笑了，没写过 lambda 总写过前端吧，能说出 lambda 鸡肋？

[coetzee]

大概扫了一下，几类人：
1：我不会，不照样好好地？不想学习，不想进步了，说啥都行，何必花时间回复帖子呢？最受不了年纪大的带节奏带风气
2：Java stream 不行啊，不如那谁谁谁？既然这样你去写别的，别在这里吹，JVM 系的 Scala 不比你吹的 C#特性更牛逼？我认为，不用追求完美，Java 在平衡历史问题和新特性之间做的还 OK ，至少比你 golang 的泛型设计强吧？更强的话你可以玩 Scala 啊，无缝对接
3：最不济的是：技能罢了？你理中客，你不是工具人？何必在这带这种节奏，一个程序员变弱就从看低自己开始，你咋不看自己看成原子运动呢？把自己看成一个熵增现象呢？把自己看成猴子呢？上帝视角用完了吗？既然这样看待技能和工具人，不如去做销售啊，IT 这行，太缺优秀的销售了~

[zr8657]

我已经开始撸 webflux 了

[x66]

@cheng6563 java.time 包本身就是由 jodatime 的作者设计并贡献给 jdk 的

[coetzee]

这圈子，特别是 Java 圈，垃圾太多，垃圾声音更多，这就是很多大神转去搞新语言的原因，这种乌烟瘴气导致语言和社区氛围极差，特别是年轻人，被这种坏风气带动的毫无编程乐趣。
单纯说 Java 这么多年，一直在语言层面进步，而且进步神速，反观一些所谓的“老开发”“老 Java”，教别人做人，以自己那点项目经验就以年轻人导师自居，嘚瑟什么呢？我见过很多程序员把编程作为职业也作为爱好，结合的很好，反观你们这些。
知道别的语言看 Java 为什么总是在歧视链最底层吗？知道为什么国内 Java 氛围就是造垃圾轮子吗？就是因为风气不好，写个 lambda 这么简单的事儿，都能阴阳怪气半天，学一下咋了？花很多时间吗？真经验丰富的人不是看几眼就会了吗？

还有阿里或者蚂蚁吹，别吹了好吗，阿里和蚂蚁都尴尬了，阿里 Java 再强，能强过 Java 委员会？能强过真 Java 开发？阿里先把创新做出来再说，再创新这么多年，大家谁不知道国内的 IT 科技呢？何必尬吹？

多看看国外的趋势，多看看第一手材料，少看阿里系，有好东西，但是别被带跑偏了，阿里也是趋势的跟风者而已，springcloud 、云原生、大数据、AI ，没有一股阿里吹起来的风，所以不用太在意你心中的“神”

[keymao]

语言是解决需求用的，只要 1+1 还等于 2 ，管他怎么算的干嘛。。 项目要求用 java8 就用 java8 要求用 kotlin 就用 kotlin 呗。

实在看不下去就换公司或者自己当老板，你说用啥就用啥对不对， 没必要和他们闹别扭。

[Suddoo]

这些“资深”程序员，自己低调点、别装逼，也就罢了

关键是还整天在那儿叫，什么底层、什么技术、什么你们都只懂皮毛，我们“资深”程序员是懂“底层”的

底层个屁，真的掌握核心技术、你倒是自己整个什么 DK 给全世界用啊。都是用别人的 API ，区别是新人 10 行写完的功能，“资深”程序员要写 100 行，或者干脆不写了，就吹牛逼，故弄玄虚

资本家也明白这个道理，所以把这些人输送给社会，也不是没有道理的，换谁都一样干，别人干活还快，还没那么多臭毛病

[coetzee]

还有一群在意 LTS ，你项目那么脆？会因为不是 LTS ，崩掉？人家 golang 就不玩这个。Java 基础设施，固定大版本，应用开发，我们一直跟踪最新版本来做，特别是 pattern match 这种，多好用~

任何选择都是成本收益的权衡罢了

[Cmdhelp]

大多数都是拿着别人家咀嚼好的东西 混口饭吃，就不要产生盲目的自信了。

[zach14c]

"请尽量让自己的回复能够对别人有帮助" --> 楼主 b 站开个教学让大家受益吧 😎

[gaifanking]

直接换 Kotlin 得了，语法更爽，还兼容 Java.

[coetzee]

真底层，不应该去研究数学吗？或者研究物理吗？再不济你研究算法或者操作系统也可以啊？何必来碰 Java 呢？你玩 JVM 理论，至少要能手写一个 JVM 吧？不然那些问别人 JVM 的，自己不羞愧吗？
Java 中的这种风气特别差，明明自己不会，而且很多艰深难懂的技术，全靠背诵才能说出 12 ，非要问，热力学定律现在能记住的人有几个？
把自己用到的知识学好做好不行吗？非要装科学家？

[zhang77555]

加班恒定的情况下写得更快并不会让你有更多收益,很多人编码无非是混口饭吃,写的快写的慢从事实上来讲也并不会影响他挣多少钱.
倒是总有些貌似热爱技术的沙雕喜欢跳出来对老板喊, 我可以干他三倍的活儿只要 1.5 倍工资,最终把自己卷没了,这种才是真的坏

[coetzee]

用好 Java ，配合团队的规则，按照最小能量原则来做项目，不要过早优化，
语法层，不要过多纠结“糖”这事儿，你 Java 都纠结糖，那 Ruby 这种咋办，齁死你？我觉得糖不糖的，团队如果都喜欢甜食的，直接选 Scala ，万事大吉

[coetzee]

@zhang77555 混淆概念，高效率这事儿和工贼混乱了，高效率是自己爽，工贼要搞事儿，你用 C 来写，也能搞事儿。持刀杀人，刀何必要背锅呢？

[wolfie]

@statumer
enhanced-for 、foreach 、stream-foreach 不都是用 iterator 吗。
哪来的更好优化一说？

[dragondove]

关于简洁和性能，使用古老的 apache commons + google guava 工具包就能解决大部分 stream 能解决的问题，而且语法更简洁，性能也更强。例如 guava 的 Maps.uniqueIndex 和 Multimaps.index 我就经常用。关于时间类型，如果使用 Date 类型，大部项目也都会有个 DateUtils 之类的工具类，内部怎么实现没人管（很多时候我会选择使用 java.time 包下的工具实现），反正最后数据是正确的就行，而时间的 parse 和 format ，我更倾向于使用 commons 的 FastDateFormat ，性能更好，占用内存小，而且线程安全。

[zhang77555]

@coetzee 我的意思就是 自己爽就行了,不应该老是跳出来说别人不行,因为最终结果大概率是别人被干掉,活到你自己头上,而挣更多的人确是老板

[cheng6563]

@x66 贡给 JDK 就完全变味了，和 java.utils.Date 转换麻烦的要死，java.sql.Date 的 toInstant 更是直接抛出异常，造成连一个通用的写法都没有。

[dragondove]

@wolfie enhanced-for 是使用 iterator 的，但是 forEach 的实现取决于 Iterable 是怎么实现的，例如 ArrayList 的 forEach 是 fori ，至于性能上，使用 forEach 会创建一个 Consumer 的匿名类对象，不过这个性能影响可以忽略不记。stream 里的 foreach 实现和 Collection 里的也是完全不一样的，stream 会创建新的对象来持有容器内的数据再作处理，不过 stream 可以使用 parrel 提升性能，如果直接使用，性能是不如 enhanced-for 或者 fori 的。

[windyboy]

会用什么不代表先进落后
代码可读性高，错漏少，适应性强，风格优美才是关键
用回 lambda 不代表你的代码质量就高

[coetzee]

会用什么不代表先进落后
不这样看待，我觉得会火箭比开飞机先进，开飞机，比开汽车的先进。
技术先进不能仅仅归为文学范畴。《代码可读性高，错漏少，适应性强，风格优美才是关键》文学虽然很重要，但是工程化的事儿，就是存在先进一说，不然何必电动车替换油车，工业革命也就不会有先进性了？
如果一直说什么本质论，我们是大清国吗？技术层面我认为，要做先进性的进步，其中肯定有更换一门更好地技术来做事。
至于什么语法代表先进性，那是另一个事儿。

[SurfaceView]

为什么要会？？？？？？

[Leviathann]

@wolfie
StackOverflow 上的一个回答的结论
Just as I expected stream implementation is fairly slower. JIT is able to inline all lambda stuff but doesn't produce as perfectly concise code as vanilla version.

下面是 brian goetz 本人的回复：
Your conclusion about performance, while valid, is overblown . There are plenty of cases where the stream code is faster than the iterative code, largely because per-element access costs is cheaper with streams than with plain iterators. And in many cases, the streams version inlines to something that is equivalent to the hand-written version. Of course, the devil is in the details; any given bit of code might behave differently

[coetzee]

为什么要写 Java ？为什么要用 Linux ？为什么要说话？为什么要发帖子？为什么要活着？问为什么的时候，不如实打实做点事，不然直接找人类终极问题答案得了：“为什么活着？”

[xloger]

我觉得更多是习惯问题，拿 Date 来说，当年就只有这个，都用习惯了，也都有自己用顺手的 DateUtil 了，然后当看到新类时会下意识想：“这个我用 XXX 方式不是也能实现么”，然后缺乏换新的动力。

除非是那种一直很烦一直很折磨的功能。比如我很想知道实现两个类的深拷贝有什么简单方便的方式么，自己管理 clone 真的很难受很难受。有的话我就肯定去更换了。