Skip to main content


Showing posts from December, 2013

Proxies done right with Guava's AbstractInvocationHandler

Snarøya Not too often but sometimes we are forced to write custom dynamic proxy class using java.lang.reflect.Proxy . There is really no magic in this mechanism and it's worth knowing even you will never really use it - because Java proxies are ubiquitous in various frameworks and libraries. The idea is quite simple: dynamically create an object that implements one or more interfaces but every time any method of these interfaces is called our custom callback handler is invoked. This handler receives a handle to a method that was called ( java.lang.reflect.Method instance) and is free to behave in any way. Proxies are often used to implement seamless mocking, caching, transactions, security - i.e. they are a foundation for AOP. Before I explain what the purpose of from the title, let's start from a simple example. Say we want to transparently run methods of given interface asynchronously in a thread pool. Popular sta

Promises and CompletableFuture

From During my talk at Warsaw Java Users Group about functional reactive programming in Java a few interesting questions came up regarding CompletableFuture capabilities. One person was interested whether it's possible to wait for the first completed future that is passing a given predicate rather than just the first one (like CompletableFuture.anyOf() ). This is similar requirement to Future.find() in Scala. It's not built into CompletableFuture but quite easy to implement using the concept of promises . Our custom implementation will take two parameters: a list of homogeneous futures and a predicate. The first future to complete that matches given predicate wins. If no future matched resulting future never ends (rather easy to change that behaviour). We will use a thread-safe and lightweight AtomicBoolean completed flag because callbacks will be invoked from multiple threads. public static <T> CompletableFuture<T> firstMatching(Predicat

Playing with Scala futures

View from Kolsåstoppen During job interviews we often give Scala developers a simple design task: to model a binary tree. The simplest but not necessarily best implementation involves Option idiom: case class Tree[+T](value: T, left: Option[Tree[T]], right: Option[Tree[T]]) Bonus points for immutability, using case class and covariance. Much better but more complex implementation involves two case classes but at least allows modelling empty trees: sealed trait Tree[+T] case object Empty extends Tree[Nothing] case class Node[+T](value: T, left: Tree[T], right: Tree[T]) extends Tree[T] Let's stick to the first idea. Now implement building a tree with arbitrary height: def apply[T](n: Int)(block: => T): Tree[T] = n match { case 1 => Tree(block, None, None) case _ => Tree( block, Some(Tree(n - 1)(block)), Some(Tree(n - 1)(block)) ) } In order to build a tree with 1024 leaves and all random variable it&