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 。

[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 真的很难受很难受。有的话我就肯定去更换了。