Miro Cupak gave a presentation on writing clean Java code in 2018. He discussed several new features in Java including factory methods for collections that provide immutable collections, improved try-with-resources for closing resources, adding private methods to interfaces, enhancements to the Stream API, extensions to Optional like ifPresentOrElse, and local variable type inference using var. He provided best practices for using each of these features such as preferring immutable collections, always using try-with-resources, keeping default methods and private methods short, and being careful when combining type inference with generics.

1. @mirocupak#VoxxedBristol
Writing clean code
with Java in 2018
Miro Cupak
VP Engineering, DNAstack
18/10/2018

2. @mirocupak#VoxxedBristol
https://theamericanscholar.org/writing-english-as-a-second-language/
http://www.osnews.com/story/19266/WTFs_m https://xkcd.com/1695/
Clarity, simplicity, brevity, humanity

3. @mirocupak#VoxxedBristol
https://www.amazon.ca/Clean-Code-Handbook-Software-
Craftsmanship/dp/0132350882/
https://www.amazon.ca/Effective-Java-3rd-Joshua-Bloch/dp/
0134685997/

4. @mirocupak#VoxxedBristol
Features
• Factory methods for collections.
• Improved try-with-resources.
• Private methods in interfaces.
• Stream API enhancements.
• Extensions to Optional.
• Type inference.

5. @mirocupak#VoxxedBristol
Factory methods for
collections

6. @mirocupak#VoxxedBristol
Factory methods for collections
• Obtain immutable collections via of/ofEntries, copies via copyOf.
• Static import java.util.Map.entry.
• Less verbose, no static initializer blocks.
• Don’t use Arrays.asList or Stream.of as shortcuts.
• Don’t use external libraries if you only need immutable collections (Guava).
• No need to worry about leaving references to underlying collections.
• Thread-safe and can be shared freely (no need for defensive copies).
• Good performance.
• Don’t create mutable collections unless necessary.

7. @mirocupak#VoxxedBristol
Improved
try-with-resources

8. @mirocupak#VoxxedBristol
Improved try-with-resources
• Always prefer try-with-resources, don’t use try-finally and definitely don’t
use finalizers to close resources.
• Be aware of convenience methods, such as
InputStream.transferTo.
• Don’t create unnecessary helper objects.

9. @mirocupak#VoxxedBristol
Private methods
in interfaces

10. @mirocupak#VoxxedBristol
Private methods in interfaces
• Default methods, like all other methods, should be short.
• DRY.
• Use private methods to keep default methods short.
• Use private methods to extract shared core of default
methods.
• Use default methods for providing standard
implementations for new interface code.
• Don’t use default methods to extend existing interfaces
unless necessary.

11. @mirocupak#VoxxedBristol
Stream API
enhancements

12. @mirocupak#VoxxedBristol
Stream API enhancements
• Be aware of new stream methods: takeWhile, dropWhile,
iterate.
• Prefer collecting into immutable collections using
toUnmodifiableList, toUnmodifiableSet,
toUnmodifiableMap.
• Avoid unnecessary null checks with ofNullable.
• Streams are suitable for more use cases now, but not all use cases.
• Don’t overuse streams as they can make code hard to read and
difficult to maintain.

13. @mirocupak#VoxxedBristol
Extensions to
Optional

14. @mirocupak#VoxxedBristol
Extensions to Optional
• Use ifPresentOrElse instead of if-isPresent construct.
• or provides a clean fluent way of chaining behaviour on Optionals.
• Be aware of orElse* methods, e.g. orElseThrow.
• Use stream to take advantage of the lazy nature of streams and
handle streams of Optionals.
• Remember that isPresent is rarely the answer.

15. @mirocupak#VoxxedBristol
Type inference

16. @mirocupak#VoxxedBristol
Diamond operator with anonymous classes
• Use <> for anonymous classes, like everywhere else.
• <> improves readability and consistency.
• Use anonymous classes only when needed (e.g. abstract classes,
interfaces with multiple abstract methods…), otherwise replace with
lambdas.

17. @mirocupak#VoxxedBristol
Local variable type inference
• Does not replace static typing.
• Generally good.
• Reduces boilerplate and improves readability.
• Helps with maintenance and refactoring.
• Use for local variables with initializers (especially constructors) and
for loops.
• Can’t use for method formals, constructor formals, method return
types, fields, catch formals, null or array initializers, lambdas,
method references, or any other kind of variable declaration.
• Consider whether to use when the generated type is not obvious.

18. @mirocupak#VoxxedBristol
Local variable type inference
• But use for complex types when breaking chained or nested
expressions with local variables.
• Primitive types might surprise you, be careful (e.g. byte, short,
long all inferred as int).
• Be very careful about combining with <> and generic methods (e.g.
var list = new ArrayList<>()).
• Probably not the best idea to use with anonymous classes.
• Use carefully chosen and expressive variable names.
• Don’t use Hungarian notation.
• Don’t rely on IDEs.

19. @mirocupak#VoxxedBristol
Local variable type inference
• Minimize the scope of local variables.
• Declare variable when it’s first used.
• Declaration not containing an initializer (i.e. you can’t use var)
often indicates the scope is not minimal.
• Prefer for loops to while loops.
• Keep methods small and focused.
• Code to the interface pattern does not work, but that’s kind of OK.

20. @mirocupak#VoxxedBristol
Questions?