Voxxed Athens 2018 - Clean Code with Java9+
0 likes83 views
Miro Cupak discusses writing clean code with Java 9 and later features. He summarizes improvements including factory methods for creating immutable collections, improved try-with-resources for closing resources, adding private methods to interfaces, enhancements to streams and Optional, a new HTTP/2 client API, type inference for local variables and diamond operators, and recommends best practices for using these features to write clean, readable code.
Voxxed Athens 2018 - Clean Code with Java9+
- 1. @mirocupak Miro Cupak VP Engineering, DNAstack 01/06/2018 Writing clean code with Java 9+
- 2. @mirocupak Clarity, simplicity, brevity, humanity !2 http://www.osnews.com/story/19266/WTFs_m https://xkcd.com/1695/ https://theamericanscholar.org/writing-english-as-a-second-language/
- 4. @mirocupak Features !4 • Factory methods for collections. • Improved try-with-resources. • Private methods in interfaces. • Stream API enhancements. • Extensions to Optional. • HTTP/2 client. • Type inference.
- 5. @mirocupak !5 Factory methods for collections
- 6. @mirocupak Factory methods for collections !6 • Obtain immutable collections via of/ofEntries methods. • Create immutable copies of collections via copyOf (Java 10). • Static import java.util.Map.entry. • Less verbose, no static initializer blocks. • Don’t use Arrays.asList or Stream.of as shortcuts for creating collections. • 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.
- 8. @mirocupak Improved try-with-resources !8 • 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 !9 Private methods in interfaces
- 10. @mirocupak Private methods in interfaces !10 • 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 !11 Stream API enhancements
- 12. @mirocupak Stream API enhancements !12 • Be aware of new stream methods: takeWhile, dropWhile, iterate. • Prefer collecting into immutable collections using toUnmodifiableList, toUnmodifiableSet, toUnmodifiableMap. • Check for convenience stream methods before converting to streams manually (e.g. Matcher, LocalDate). • 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 !13 Extensions to Optional
- 14. @mirocupak Extensions to Optional !14 • 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. the new orElseThrow (Java 10). • Use stream to take advantage of the lazy nature of streams and handle streams of Optionals. • Remember that isPresent is rarely the answer.
- 16. @mirocupak HTTP/2 client !16 • Clean separation: HttpClient, HttpRequest, HttpResponse. • HttpURLConnection is not pleasant to use. • Avoid APIs with side effects. • The new client API is versatile, flexible and clean. • Prefer functionality in the JDK to external libraries. • But aware it’s an incubator module.
- 18. @mirocupak Diamond operator with anonymous classes !18 • 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.
- 19. @mirocupak Local variable type inference !19 • 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. • 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).
- 20. @mirocupak Local variable type inference !20 • 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. • 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.
- 21. @mirocupak Questions? !21 More info: Session notes on Twitter. Blog: https://mirocupak.com/