“Lambdas Chops: Recipes for simpler more expressive code”
Speaker: Ian Robertson
slidehare.net/nainostrebor
For more blog posts from JavaOne, see the table of contents
Disclaimer: These are now the most performant way of doing things. If you have I/O or database code, it won’t be a significant difference.
Did one slide review of lambdas as “test” for whether kow enough to follow rest of session. [good idea]
Null safe navigation
- In Groovy, a?.getX()?.getY()
- Call method if object is non-null, otherwise just return null
- Best route is to refactor to return Optional from the getters
- If can’t refactor: Optional.ofNullable(employee).ap(Employee::getAddress).map(Address::getCity).orElse(null)
- By chaining Optional can decide what to do
First non null
- commons-lang has ObjectUtils.firstNonNull
- Works will if values are cheap to provide
- If expensive/time consuming, waiting for wasted work
- firstNonNull(customer.getCart():getRecommendations, this::getBestSellers)
- and firstNonNull now would have- Stream.of(values).map(Supplier:get).filter(Objects:nonNull).findFIrst().orElse(null)
Multi-method interfaces
- Helper methods can create instances from one or more lambdas
- Showed with SimpleFieVisitor. [i don’t see a lambda or method reference here. He mentioned a lambda, but there are no abstract methods now]
Exceptions
- forEach(File::createNewFile) – doesn’t compile because throws IOException
- Tried to solve in language and couldn’t.
- Can catch exception in lambda and convert to runtime exception, but now code is long
- jOOL library create companion interface that allows checked exceptions and converts to runtime exception
- now write forEach(Unchecked.consumer(File::createNewFile))
Design Pattern
- Dispose pattern – close in proper place [no null check in example]
- Try-with-resources added in Java 7
- Can forget; poor API that lets you forget
- Must implement AutoCloseable
- Can have close logic or lock/unlock in one place and pass lambda [still have to remember to call that]
- Vavr (Java upside down) library has good library for lazy evaluation (double checked locking pattern) – pass lambda wih work
Type safety
- Many APIs rely on String representation of method names
- ex: commmons-beanutils takes method name for comparators. “stringly typed”
- JDK added API that takes method reference Comparator.comparing(Person::getLastName).thenComparing(Person:getFirstName)
- Now type safe
JUnit 5 Parameterized Tests
- @MethodSource has “stringly typed” problem. Also, no way to know passing right # parameters and types
- Alternatively can use @TestFactory and DynamicTests to have compile time type safety
- Harder to read with tuples. Can improve further with helper method per combo and have tests use it.
- [the lack of type safety doesn’t seem like a big deal here since run tests regularly so would know if mismatch. And parameterized tests are much easier to read ]
- Wrote LambdataRunner to do this in JUnit 4
Best Practices
- Have more single method interfaces. Provide static helper methods to create
- Use existing interfaces where can instead of writing own. Easier because already know what it is
- Avoid overloading method names to accept different lambas of same “shape”. Compiler says lamda ambigious and require lients to cast
My take: I really liked the discussion of pros and cons. And the emoticons were fun – happy, sad, angry, meh. I don’t like the JUnit example, but the rest sound like things I’d do/try.