Streams in JDK 8: The Good, the Bad, and the Ugly
summary
Shows concrete JDK 8 pitfalls and fixes: code that returns null instead of Optional and calls String.split twice (inefficient), a URLDecoder that throws a checked UnsupportedEncodingException so extraction is moved to a helper and logging is used, replacing three-line dense streams with a readable stream/filter/collect using groupingBy to build month→day→count maps, replacing forEach/LongAdder state with filter/count, using Collectors.joining instead of O(n^2) reduce, and warning that parallel streams use the common ForkJoinPool (JDK9 fixes container CPU visibility).
AI-written summary · about
chapters (21)
- 0:00Intro
- 0:32Goals Of This Session
- 2:10Problem To Solve
- 3:01Non-Stream Code
- 3:24My Stream Code (Ugly)
- 8:52Stream Code (Better)
- 10:10Stream Code (Better JDK 9)
- 13:47Not Thinking Functional
- 16:50Almost Functional (But Not Quite)
- 20:31Mixed Iteration (Bad)
- 23:08Internal Iteration (But Ugly)
- 24:11Internal Iteration (Good)
- 26:00Mixed Interation (Still Bad)
- 31:06Simple Exercise
- 33:03Alternative Reduction (Bad)
- 35:10Reduction By Collection (Complex)
- 39:08Stream Reuse (Good or Bad?)
- 40:51Multi-Sort (Bad)
- 41:27Parallel Streams Are Faster, Right?
- 43:42Custom Pools For Parallel Streams
- 45:19Conclusions
related talks
47mThe Dark Side of Java 8 - Lessons Learned
01h 05mJava 8: The Good, the Bad and the Ugly
49mJava 8: the good, the bad and the ugly
32mThe Dark Side of Java 8
49mJava Streams: Beyond The Basics
50m10+ new features you ought to know using Java 8
51mIf Streams Are So Great, Let’s Use Them Everywhere... Right??
55mTransforming Your Code to Java 8