DevNexus 2019 – Writing Better Functional Code – Brian Vermeer

See the table of contents for my other blog posts from the conference



  • Function definition not bound to an identifier
  • arguments being passed to higher order functions or used to construct higher order functions
  • In Java, like an anonymous inner function. Only exists at runtime

Lambda length

  • Want lambdas to be one line
  • If more than one line, probably have a separation of concerns problem
  • If more than one line, put it in a method with a reasonable name and use a method reference

Should you return a stream

  • A stream is not a data structure
  • Can’t reuse
  • Don’t store in a variable. Invites people to use it twice and fail.
  • No way to programmatically determine if a stream has been used
  • Useful to return streams: for private intermediate function, when new stream created every time or when result is very large or infinite
  • If not sure, return a collection instead of a stream

Mutable objects

  • Functional programming avoids changing state and mutable data
  • Less moving parts on immutable operations
  • “A stream cannot mutate” (well; isn’t supposed to)
  • Better to make a copy of the object with the desired state rather than changing the original

For each

  • It’s just a for loop
  • It can mutate state, have side effects, etc

Order of operations in stream

  • Logic
  • Infinite streams – can keep generating values and won’t stop if don’t haven’t limit or something that makes finite

Infinite stream

  • Be careful
  • Only use if needed
  • Fork/join is in an infinite pool. Will get slower and not faster with infinite data

Create higher order functions

  • Avoid duplicate code by changing “middle” of code.


  • Java’s implementation fo the Maybe Monad
  • Encapsulation to handle possible null
  • Forces user to unpack/handle before using it.
  • Don’t set/return null for an optional. Use Optional.empty() instead
  • Use isPresent/get as a last resort. The other Optional methods are better
  • Make sure orElse() doesn’t have any side effects and only to assign a default value. Otherwise use orElseGet()

Checked exceptions and lambdas

  • Doesn’t compile
  • If want to do at point where exception happens, wrap in runtime exception and continue. Problematic because need to do it every time.
  • Alternatively, can create own functional interface that declares a checked exception and a helper method that calls the functional interface and catches the exception. This is even more ugly because abstracted further away. It’s like a wrapper function.
  • [he didn’t mention changing to an unchecked exception or a static utility to just wrap the method].
  • If want to ignore exception and process rest of stream, can use Either (a pair object), can keep track of whether there is an exception. Can implement Either yourself or use Fibers library

My take

Good content. The functional programming slide “highlighted” key words with worse contrast, but not a big deals. While this wasn’t new to me, it is good review. And if gives me arguments for my teammates when they use these anti-patterns. I like that he used some live coding. The stuff at the end was new (Either), but I felt like we were running out of time.

Leave a Reply

Your email address will not be published. Required fields are marked *