• Concurrency: Java Futures and Kotlin Coroutines

    A long time ago, one had to manually start new threads when wanting to run code concurrently in Java. Not only was this hard to write, it was easy to introduce bugs that were hard to find. Testing, reading and maintaining such code was no walk in the park either. Since that time - and with a little incentive coming from multi-core machines, the Java API has evolved to make developing concurrent code easier. Meanwhile, alternative JVM languages also have their opinion about helping developers write such code. In this post, I’ll compare how it’s implemented in Java and Kotlin.

    To keep the post focused, I deliberately left out performance to write about code readability.

    About the use-case

    The use-case is not very original. We need to call different web services. The naive solution would be to call them sequentially, one after the other, and collect the result of each of them. In that case, the overall call time would be the sum of the call time of each service. An easy improvement is to call them in parallel, and wait for the last one to finish. Thus, performance improves from linear to constant - or for the more mathematically inclined, from o(n) to o(1).

    To simulate calling a web service with a delay, let’s use the following code (in Kotlin because this is so much less verbose):

    class DummyService(private val name: String) {
        private val random = SecureRandom()
        val content: ContentDuration
            get() {
                val duration = random.nextInt(5000)
                return ContentDuration(name, duration)
    data class ContentDuration(val content: String, val duration: Int)

    The Java Future API

    Java offers a whole class hierarchy to handle concurrent calls. It’s based on the following classes:

    A Callable is a "task that returns a result". From another view point, it's similar to a function that takes no parameter and returns this result.
    A Future is "the result of an asynchronous computation". Also, "The result can only be retrieved using method get when the computation has completed, blocking if necessary until it is ready". In other words, it represents a wrapper around a value, where this value is the outcome of a calculation.
    Executor Service
    An ExecutorService "provides methods to manage termination and methods that can produce a Future for tracking progress of one or more asynchronous tasks". It is the entry point into concurrent handling code in Java. Implementations of this interface - as well are more specialized ones, can be obtained through static methods in the Executors class.

    This is summarized in the following class diagram:

    Calling our services using the concurrent package is a 2-steps process.

    Creating a collection of callables

    First, there need to be a collection of Callable to pass to the executor service. This is how it might go:

    1. From a stream of service names
    2. For each service name, create a new dummy service initialized with the string
    3. For every service, return the service’s getContent() method reference as a Callable. This works because the method signature, matches Callable.call() and Callable is a functional interface.

    This is the preparation phase. It translates into the following code:

    List<Callable<ContentDuration>> callables = Stream.of("Service A", "Service B", "Service C")
          .map(service -> (Callable<ContentDuration>) service::getContent)

    Processing the callables

    Once the list has been prepared, it’s time for the ExecutorService to process it aka the “real work”.

    1. Create a new executor service - any will do
    2. Pass the list of Callable to the executor service, and stream the resulting list of Future
    3. For every future,
    4. Either return the result
    5. Or handle the exception

    The following snippet is a possible implementation:

    ExecutorService executor = Executors.newWorkStealingPool();
    List<ContentDuration> results = executor.invokeAll(callables).stream()
        .map(future -> {
             try { return future.get(); } 
             catch (InterruptedException | ExecutionException e) { throw new RuntimeException(e); }

    The Future API, but in Kotlin

    Let’s face it, while Java makes it possible to write concurrent code, reading and maintaining it is not that easy, mainly due to:

    • Going back and forth between collections and streams
    • Handling checked exception in lambdas
    • Casting explicitly

    Just porting the above code to Kotlin removes those limitations and makes it more straightforward:

    var callables: List<Callable<ContentDuration>> = arrayOf("Service A", "Service B", "Service C")
        .map { DummyService(it) }
        .map { Callable<ContentDuration> { it.content } }
    val executor = Executors.newWorkStealingPool()
    val results = executor.invokeAll(callables).map { it.get() }

    Kotlin Coroutines

    With version 1.1 of Kotlin comes a new experimental feature called coroutines.

    Basically, coroutines are computations that can be suspended without blocking a thread. Blocking threads is often expensive, especially under high load […]. Coroutine suspension is almost free, on the other hand. No context switch or any other involvement of the OS is required.

    The leading design principle behind coroutines is that they must feel like sequential code but run like concurrent code. They are based on the following (simplified) class diagram:

    Nothing beats the code itself though. Let’s implement the same as above, but with coroutines in Kotlin instead of Java futures.

    As a pre-step, let’s just extend the service to ease further processing by adding a new computed property wrapped around content, of type Deferred:

    val DummyService.asyncContent: Deferred<ContentDuration>
        get() = async(CommonPool) { content }

    This is standard Kotlin extension property code, but notice the CommonPool parameter. This is the magic that makes the code run concurrent. It’s a companion object (i.e. a singleton) that uses a multi-fallback algorithm to get an ExecutorService instance.

    Now, on to the code flow proper:

    1. Coroutines are handled inside a block. Declare a variable list outside the block to be assigned inside it
    2. Open the synchronization block
    3. Create the array of service names
    4. For each name, create a service and return it
    5. For each service, get its async content (declared above) and return it
    6. For each deferred, get the result and return it
    // Variable must be initialized or the compiler complains
    // And the variable cannot be used afterwards
    var results = runBlocking {
        arrayOf("Service A", "Service B", "Service C")
            .map { DummyService(it) }
            .map { it.asyncContent }
            .map { it.await() }


    The Future API is not so much a problem than the Java language itself. As soon as the code is translated into Kotlin, readability improves a lot. Yet, having to create a collection to pass to the executor service breaks the nice functional pipeline.

    On the coroutines side, remember that they are still experimental. Despite that, code does look sequential - and is thus more readable, and behaves parallel.

    Categories: Java Tags: futurekotlincoroutine
  • Java Service Loader vs Spring Factories Loader

    Coloured factory

    Inversion of Control is not only possible at the class level, but at the module level. OSGi has been doing it for a long time. However, there are IoC approaches directly available in Java, as well as in Spring.

    Java Service Loader

    Out-of-the-box, the Java API offers a specific form of Inversion of Control. It’s implemented by the Service Loader class. It is designed to locate implementation classes of an interface on the classpath. This way allows to discover which available implementations of an interface are available on the classpath at runtime, and thus paves the way for modules designed around a clean separation between an API module - i.e. JAR, and multiple implementation modules.

    This is the path chosen by the logging framework, SLF4J. SLF4J itself is just the API, while different implementations are available (_e.g. Logback, Log4J, etc.). SLF4J clients only interact with the SLF4J API, while the implementation available on the classpath takes care of the nitty-gritty details at runtime.

    It’s implemented as a file located in the META-INF/services folder of a JAR. The name of the file is the fully qualified name of the interface, while its content is a list of qualified names of available implementations. For example, for an interface ch.frankel.blog.serviceloader.Foo, there must be a file named META-INF/services/ch.frankel.blog.serviceloader.Foo which content might look like this:


    Note classes listed above must implement the ch.frankel.blog.serviceloader.Foo interface.

    From a code perspective, it’s very straightforward:

    ServiceLoader<Foo> loader = ServiceLoader.load(Foo.class);

    Service Loader Spring integration

    Core Spring offers an integration with the above Service Loader via the factory beans. For example, the following code assumes there will be a least of candidate implementations:

    public class ServiceConfiguration {
        public ServiceListFactoryBean serviceListFactoryBean() {
            ServiceListFactoryBean serviceListFactoryBean = new ServiceListFactoryBean();
            return serviceListFactoryBean;
    Object object = serviceListFactoryBean.getObject();

    Obviously, this requires further operations to get the data in the right form (hint: it’s a linked list).

    Spring Factories Loader

    In parallel to the Java Service Loader, Spring offers another Inversion of Control implementation. There’s only a single property file involved, it must be named spring.factories and located under META-INF. From a code perspective, the file is read through the SpringFactoriesLoader.loadFactories() static method - yes, for Spring, it’s quite a shock.

    Client code couldn’t get any simpler:

    List<Foo> foos = SpringFactoriesLoader.loadFactories(Foo.class, null);

    Note the 2nd argument is the optional class loader.

    Compared to the Java Service Loader, the differences are two-fold:

    1. Whether one file format is better .i.e. more readable or more maintainable, than the other is a matter of personal taste.
    2. There’s no requirement in spring.factories for the key to be an interface and for the values to implement it. For example, Spring Boot uses this approach to handle auto-configuration beans: the key is an annotation i.e. org.springframework.boot.autoconfigure.EnableAutoConfiguration while values are classes annotated with @Configuration. This allows for a much more flexible design, if used wisely.
  • Fixing my own Spring Boot starter demo

    Spring Boot logo

    Since one year or so, I try to show the developer community that there’s no magic involved in Spring Boot but rather just straightforward software engineering. This is achieved with blog posts and conference talks. At jDays, Stéphane Nicoll was nice enough to attend my talk and pointed out an issue in the code. I didn’t fix it then, and it came back to bite me last week during a Pivotal webinar. Since a lesson learned is only as useful as its audience, I’d like to share my mistake with the world, or at least with you, dear readers.

    The context is that of a Spring Boot starter for the XStream library:

    XStream is a simple library to serialize objects to XML and back again.

    1. (De)serialization capabilities are implemented as instance methods of the XStream class
    2. Customization of the (de)serialization process is implemented through converters registered in the XStream instance

    The goal of the starter is to ease the usage of the library. For example, it creates an XStream instance in the context if there’s none already:

    public class XStreamAutoConfiguration {
        public XStream xStream() {
            return new XStream();

    Also, it will collect all custom converters from the context and register them in the existing instance:

    public class XStreamAutoConfiguration {
        public XStream xStream() {
            return new XStream();
        public Collection<Converter> converters(XStream xstream, Collection<Converter> converters) {
            return converters;

    The previous snippet achieves the objective, as Spring obediently inject both xstream and converters dependency beans in the method. Yet, a problem happened during the webinar demo: can you spot it?

    If you answered about an extra converters bean registered into the context, you are right. But the issue occurs if there’s another converters bean registered by the client code, and it’s of different type i.e. not a Collection. Hence, registration of converters must not happen in beans methods, but only in a @PostConstruct one.

    • Option 1

      The first option is to convert the @Bean to @PostConstruct.

      public class XStreamAutoConfiguration {
        public XStream xStream() {
            return new XStream();
        public void register(XStream xstream, Collection<Converter> converters) {

      Unfortunately, @PostConstruct doesn’t allow for methods to have arguments. The code doesn’t compile.

    • Option 2

      The alternative is to inject both beans into attributes of the configuration class, and use them in the @PostConstruct-annotated method.

      public class XStreamAutoConfiguration {
        private XStream xstream;
        private Collection<Converter> converters;
        public XStream xStream() {
            return new XStream();
        public void register() {

    This compiles fine, but Spring enters a cycle trying both to inject the XStream instance into the configuration and to create it as a bean at the same time.

    • Option 3

      The final (and only valid) option is to learn from the master and use another configuration class - a nested one. Looking at Spring Boot code source, it’s obviously a pattern.

      The final code looks like this:

      public class XStreamAutoConfiguration {
        public XStream xStream() {
            return new XStream();
        public static class XStreamConverterAutoConfiguration {
            private XStream xstream;
            private Collection<Converter> converters;
            public void registerConverters() {
                converters.forEach(converter -> xstream.registerConverter(converter));

    The fixed code is available on Github. And grab the webinar while it’s hot.

    Categories: Java Tags: Spring Bootdesign
  • Custom collectors in Java 8

    Among the many features available in Java 8, streams seem to be one of the biggest game changers regarding the way to write Java code. Usage is quite straightforward: the stream is created from a collection (or from a static method of an utility class), it’s processed using one or many of the available stream methods, and the collected back into a collection or an object. One generally uses one of the static method that the Collectors utility class offers:

    • Collectors.toList()
    • Collectors.toSet()
    • Collectors.toMap()
    • etc.

    Sometimes, however, there’s a need for more. The goal of this post is to describe how to achieve that.

    The Collector interface

    Every one of the above static methods returns a Collector. But what is a Collector? The following is a simplified diagram:

    Interface From the JavaDocs
    Supplier Represents a supplier of results. There is no requirement that a new or distinct result be returned each time the supplier is invoked.
    BiConsumer Represents an operation that accepts two input arguments and returns no result. Unlike most other functional interfaces, BiConsumer is expected to operate via side-effects.
    Function Represents a function that accepts one argument and produces a result.
    BinaryOperator Represents an operation upon two operands of the same type, producing a result of the same type as the operands. This is a specialization of BiFunction for the case where the operands and the result are all of the same type.

    The documentation of each dependent interface doesn’t tell much, apart from the obvious. Looking at the Collector documentation yields a little more:

    A Collector is specified by four functions that work together to accumulate entries into a mutable result container, and optionally perform a final transform on the result. They are:

    • creation of a new result container (supplier())
    • incorporating a new data element into a result container (accumulator())
    • combining two result containers into one (combiner())
    • performing an optional final transform on the container (finisher())

    The Stream.collect() method

    The real insight comes from the Stream.collect() method documentation:

    Performs a mutable reduction operation on the elements of this stream. A mutable reduction is one in which the reduced value is a mutable result container, such as an ArrayList, and elements are incorporated by updating the state of the result rather than by replacing the result. This produces a result equivalent to:

        R result = supplier.get();
        for (T element : this stream)
            accumulator.accept(result, element);
        return result;

    Note the combiner() method is not used - it is only used within parallel streams, and for simplification purpose, will be set aside for the rest of this post.


    Let’s have some examples to demo the development of custom collectors.

    Single-value example

    To start, let’s compute the size of a collection using a collector. Though not very useful, it’s a good introduction. Here are the requirements for the 4 interfaces:

    1. Since the end result should be an integer, the supplier should probably also return some kind of integer. The problem is that neither int nor Integer are mutable, and this is required for the next step. A good candidate type would be MutableInt from Apache Commons Lang.
    2. The accumulator should only increment the MutableInt, whatever the element in the collection is.
    3. Finally, the finisher just returns the int value wrapped by the MutableInt.

    Source is available on Github.

    Grouping example

    The second example shall be more useful. From a collection of strings, let’s create a Apache Commons Lang multi-valued map:

    • The key should be a char
    • The corresponding values should be the strings that start with this char
    1. The supplier is pretty straightforward, it returns a MultiValuedMap instance
    2. The accumulator just calls the put method from the multi-valued map, using the above “specs”
    3. The finisher returns the map itself

    Source is available on Github.

    Partitioning example

    The third example matches a use-case I encountered this week: given a collection and a predicate, dispatch elements that match into a collection and elements that do not into another.

    1. As the supplier returns a single instance, a new data structure e.g. DoubleList should first be designed
    2. The accumulator must be initialized with the predicate, so that the accept() contract method signature is the same.
    3. As for the above example, the finisher should return the DoubleList itself

    Source is available on Github.

    Final consideration

    Developing a custom collector is not that hard, provided one understands the basic concepts behind it.

    The real issue behind collectors is the whole Stream API. Streams need to be created first and then collected afterwards. Newer languages, with Functional Programming paradigm designed from the start - such as Scala or Kotlin, provide collections with such capabilities directly backed-in.

    For example, to filter out something from a map in Java:

            .filter( entry -> entry.getKey().length() == 4)
            .collect(Collectors.toMap(Map.Entry::getKey, Map.Entry::getValue));

    That would translate as the following in Kotlin:

    map.entries.filter { it.key.length == 4 }
    Categories: Java Tags: java 8lambdacollector
  • Kotlin for front-end developers

    Kotlin logo

    I assume that readers are already familiar with the Kotlin language. Advertised from the site:

    Statically typed programming language for the JVM, Android and the browser 100% interoperable with Java™

    — Headline from the Kotlin website

    Kotlin first penetrated the Android ecosystem and has seen a huge adoption there. There’s also a growing trend on the JVM, via Spring Boot. Since its latest 1.1 release, Kotlin also offers a production-grade Kotlin to JavaScript transpiler. This post is dedicated to the latter.

    IMHO, the biggest issue regarding the process of transpiling Kotlin to JavaScript is that documentation is only aimed at server-side build tools just as Maven and Gradle - or worse, the IntelliJ IDEA IDE. Those work very well for backend-driven projects or prototypes, but is not an incentive to front-end developers whose bread and butter are npm, Grunt/Gulp, yarn, etc.

    Let’s fix that by creating a simple Google Maps using Kotlin.

    Managing the build file

    This section assumes:

    • The Grunt command-line has already been installed, via npm install -g grunt-cli
    • The kotlin package has been installed and the kotlin compiler is on the path. I personally use Homebrew - brew install kotlin

    The build file looks like the following:

    module.exports = function (grunt) {
            clean: 'dist/**',
            exec: {
                cmd: 'kotlinc-js src -output dist/script.js' (1)
            copy: { (2)
                files: {
                    expand: true,
                    flatten: true,
                    src: ['src/**/*.html', 'src/**/*.css'],
                    dest: 'dist'
        grunt.registerTask('default', ['exec', 'copy']);
    1 Transpiles all Kotlin files found in the src folder to a single JavaScript file
    2 Copies CSS and HTML files to the dist folder

    Bridging Google Maps API in Kotlin

    The following snippet creates a Map object using Google Maps API which will be displayed on a specific div element:

    var element = document.getElementById('map');
    new google.maps.Map(element, {
    	center: { lat: 46.2050836, lng: 6.1090691 },
        zoom: 8

    Like in TypeScript, there must be a thin Kotlin adapter to bridge the original JavaScript API. Unlike in TypeScript, there’s no existing repository of such adapters. The following is a naive first draft:

    external class Map(element: Element?, options: Json?)
    The external keyword is used to tell the transpiler the function body is implemented in another file - or library in that case.

    The first issue comes from a name collision: Map is an existing Kotlin class and is imported by default. Fortunately, the @JsName annotation allows to translate the name at transpile time.

    external class GoogleMap(element: Element?, options: Json?)

    The second issue occurs because the original API is in a namespace: the object is not Map, but google.maps.Map. The previous annotation doesn’t allow for dots, but a combination of other annotations can do the trick:

    external class GoogleMap(element: Element?, options: Json?)

    This still doesn’t work - it doesn’t even compile, as @JsQualifier cannot be applied to a class. The final working code is:

    package google.maps
    external class GoogleMap(element: Element?, options: Json?)

    Calling Google Maps

    Calling the above code is quite straightforward, but note the second parameter of the constructor is of type Json. That for sure is quite different from the strongly-typed code which was the goal of using Kotlin. To address that, let’s create real types:

    internal class MapOptions(val center: LatitudeLongitude, val zoom: Byte)
    internal class LatitudeLongitude(val latitude: Double, val longitude: Double)

    And with Kotlin’s extension function - and an out-of-the-box json() function, let’s make them able to serialize themselves to JSON:

    internal fun LatitudeLongitude.toJson() = json("lat" to latitude, "lng" to longitude)
    internal fun MapOptions.toJson() = json("center" to center.toJson(), "zoom" to zoom)

    This makes it possible to write the following:

    fun initMap() {
        val div = document.getElementById("map")
        val latLng = LatitudeLongitude(latitude = -34.397, longitude = 150.644)
        val options = MapOptions(center = latLng, zoom = 8)
        GoogleMap(element = div, options = options.toJson())


    We could stop at this point, with the feeling to have achieved something. But Kotlin allows much more.

    The low hanging fruit would be to move the JSON serialization to the Map constructor:

    internal class KotlinGoogleMap(element: Element?, options: MapOptions) : GoogleMap(element, options.toJson())
    KotlinGoogleMap(element = div, options = options)

    Further refinements

    The "domain" is quite suited to be written using a DSL. Let’s update the "API":

    external open class GoogleMap(element: Element?) {
        fun setOptions(options: Json)
    internal class MapOptions {
        lateinit var center: LatitudeLongitude
        var zoom: Byte = 1
        fun center(init: LatitudeLongitude.() -> Unit) {
            center = LatitudeLongitude().apply(init)
        fun toJson() = json("center" to center.toJson(), "zoom" to zoom)
    internal class LatitudeLongitude() {
        var latitude: Double = 0.0
        var longitude: Double = 0.0
        fun toJson() = json("lat" to latitude, "lng" to longitude)
    internal class KotlinGoogleMap(element: Element?) : GoogleMap(element) {
        fun options(init: MapOptions.() -> Unit) {
            val options = MapOptions().apply(init)
            setOptions(options = options.toJson())
    internal fun kotlinGoogleMap(element: Element?, init: KotlinGoogleMap.() -> Unit) = KotlinGoogleMap(element).apply(init)

    The client code now can be written as:

    fun initMap() {
        val div = document.getElementById("map")
        kotlinGoogleMap(div) {
            options {
                zoom = 6
                center {
                    latitude = 46.2050836
                    longitude = 6.1090691


    Though the documentation is rather terse, it’s possible to only use the JavaScript ecosystem to transpile Kotlin code to JavaScript. Granted, the bridging of existing libraries is a chore, but this is only a one-time effort as the community starts sharing their efforts. On the other hand, the same features that make Kotlin a great language to use server-side - e.g. writing a DSL, also benefit on the front-end.

    Categories: Development Tags: JavaScriptKotlinfront-end
  • Common code in Spring MVC, where to put it?

    Spring Boot logo

    During my journey coding an actuator for a non-Spring Boot application, I came upon an interesting problem regarding where to actually put a snippet of common code. This post tries to list all available options, and their respective pros and cons in a specific context.

    As a concrete example, let’s use the REST endpoint returning the map of all JVM properties accessible through the /jvmprops sub-context. Furthermore, I wanted to offer the option to search not only for a single property e.g. /jvmprops/java.vm.vendor but also to allow for filtering for a subset of properties e.g. /jvmprops/java.vm.*.

    The current situation

    The code is designed around nothing but boring guidelines for a Spring application. The upper layer consists of controllers. They are annotated with @RestController and provide REST endpoints made available as @RequestMapping-annotated methods. In turn, those methods call the second layer implemented as services.

    As seen above, the filter pattern itself is the last path segment. It’s mapped to a method parameter via the @PathVariable annotation.

    @RestController class JvmPropsController(private val service: JvmPropsService) {
      @RequestMapping(path = arrayOf("/jvmprops/{filter}"), method = arrayOf(GET))
      fun readJvmProps(@PathVariable filter: String): Map<String, *> = service.getJvmProps()

    To effectively implement filtering, the path segment allows star characters. In Java however, string matching is achieved via regular expression. It’s then mandatory to “translate” the simple calling pattern to a full-fledge regexp. Regarding the above example, not only the dot character needs to be escaped - from . but to \\., but the star character needs to be translated accordingly - from * to .*:

    val regex = filter.replace(".", "\\.").replace("*", ".*")

    Then, the associated service returns the filtered map, which is in turn returned by the controller. Spring Boot and Jackson take care of JSON serialization.

    Straightforward alternatives

    This is all fine and nice, until additional map-returning endpoints are required (for example, to get environment variables), and the above snippet ends up being copied-pasted in each of them.

    There surely must be a better solution, so where factor this code?

    In a controller parent class

    The easiest hack is to create a parent class for all controllers, put the code there and call it explicitly.

    abstract class ArtificialController() {
        fun toRegex(filter: String) = filter.replace(".", "\\.").replace("*", ".*")
    @RestController class JvmProps(private val service: JvmPropsService): ArtificialController() {
      @RequestMapping(path = arrayOf("/jvmprops/{filter}"), method = arrayOf(GET))
      fun readJvmProps(@PathVariable filter: String): Map<String, *> {
        val regex = toRegex(filter)
        return service.getJvmProps(regex)

    This approach has three main disadvantages:

    1. It creates an artificial parent class just for the sake of sharing common code.
    2. It’s necessary for other controllers to inherit from this parent class.
    3. It requires an explicit call, putting the responsibility of the transformation in the client code. Chances are high that no developer but the one who created the method will ever use it.

    In a service parent class

    Instead of setting the code in a shared method of the controller layer, it can be set in the service layer.

    The same disadvantages as above apply.

    In a third-party dependency

    Instead of an artificial class hierarchy, let’s introduce an unrelated dependency class. This translates into the following code.

    class Regexer {
      fun toRegex(filter: String) = filter.replace(".", "\\.").replace("*", ".*")
    @RestController class JvmProps(private val service: JvmPropsService,
                                   private val regexer: Regexer) {
      @RequestMapping(path = arrayOf("/jvmprops/{filter}"), method = arrayOf(GET))
      fun readJvmProps(@PathVariable filter: String): Map<String, *> {
        val regex = regexer.toRegex(filter)
        return service.getJvmProps(regex)

    While favoring composition over inheritance, this approach still leaves out a big loophole: the client code is required to call the shared one.

    In a Kotlin extension function

    If one is allowed to use alternate languages on the JVM, it’s possible to benefit for Kotlin’s extension functions:

    interface ArtificialController
    fun ArtificialController.toRegex(filter: String) = filter.replace(".", "\\.").replace("*", ".*")
    @RestController class JvmProps(private val service: JvmPropsService): ArtificialController {
      @RequestMapping(path = arrayOf("/jvmprops/{filter}"), method = arrayOf(GET))
      fun readJvmProps(@PathVariable filter: String): Map<String, *> {
        val regex = toRegex(filter)
        return service.getJvmProps(regex)

    Compared to putting the code in a parent controller, at least the code is localized to the file. But the same disadvantages still apply, so the gain is only marginal.

    More refined alternatives

    Refactorings described above work in every possible context. The following options apply specifically for (Spring Boot) web applications.

    They all follow the same approach: instead of explicitly calling the shared code, let’s somehow wrap controllers in a single component where it will be executed.

    In a servlet filter

    In a web application, code that needs to be executed before/after different controllers are bound to take place in a servlet filter.

    With Spring MVC, this is achieved through a filter registration bean:

    fun filterBean() = FilterRegistrationBean().apply {
      urlPatterns = arrayListOf("/jvmProps/*")
      filter = object : Filter {
        override fun destroy() {}
        override fun init(config: FilterConfig) {}
        override fun doFilter(req: ServletRequest, resp: ServletResponse, chain: FilterChain) {
          chain.doFilter(httpServletReq, resp)
          val httpServletReq = req as HttpServletRequest
          val paths = request.pathInfo.split("/")
          if (paths.size > 2) {
            val subpaths = paths.subList(2, paths.size)
            val filter = subpaths.joinToString("")
            val regex = filter.replace(".", "\\.")
                              .replace("*", ".*")
            // Change the JSON here...

    The good point about the above code is it doesn’t require controllers to call the shared code explicitly. There’s a not-so-slight problem however: at this point, the map has already been serialized into JSON, and been processed into the response. It’s mandatory to wrap the initial respons in a response wrapper before proceeding with the filter chain and process the JSON instead of an in-memory data structure.

    Not only is this way quite fragile, it has a huge impact on performance.

    In a Spring MVC interceptor

    Moving the above code from a filter in a Spring MVC interceptor unfortunately doesn’t improve anything.

    In an aspect

    The need of translating the string parameter and to filter the map are typical cross-cutting concerns. This is a typical use-case fore Aspect-Oriented Programming. Here’s what the code looks like:

    @Aspect class FilterAspect {
      @Around("execution(Map ch.frankel.actuator.controller.*.*(..))")
      fun filter(joinPoint: ProceedingJoinPoint): Map<String, *> {
        val map = joinPoint.proceed() as Map<String, *>
        val filter = joinPoint.args[0] as String
        val regex = filter.replace(".", "\\.").replace("*", ".*")
        return map.filter { it.key.matches(regex.toRegex()) }

    Choosing this option works in the intended way. Plus, the aspect will be applied automatically to all methods of all classes in the configured package that return a map.

    In a Spring MVC advice

    There’s a nice gem hidden in Spring MVC: a specialized advice being executed just after the controller returns but before the returned value is serialized in JSON format (thanks to @Dr4K4n for the hint).

    The class just needs to:

    1. Implement the ResponseBodyAdvice interface
    2. Be annotated with @ControllerAdvice to be scanned by Spring, and to control which package it will be applied to
    class TransformBodyAdvice(): ResponseBodyAdvice<Map<String, Any?>> {
      override fun supports(returnType: MethodParameter, converterType: Class<out HttpMessageConverter<*>>) =
      returnType.method.returnType == Map::class.java
      override fun beforeBodyWrite(map: Map<String, Any?>, methodParameter: MethodParameter,
                mediaType: MediaType, clazz: Class<out HttpMessageConverter<*>>,
                serverHttpRequest: ServerHttpRequest, serverHttpResponse: ServerHttpResponse): Map<String, Any?>  {
        val request = (serverHttpRequest as ServletServerHttpRequest).servletRequest
        val filterPredicate = getFilterPredicate(request)
        return map.filter(filterPredicate)
      private fun getFilterPredicate(request: HttpServletRequest): (Map.Entry<String, Any?>) -> Boolean {
        val paths = request.pathInfo.split("/")
        if (paths.size > 2) {
          val subpaths = paths.subList(2, paths.size)
          val filter = subpaths.joinToString("")
          val regex = filter.replace(".", "\\.")
                            .replace("*", ".*")
          return { it.key.matches(regex) }
        return { true }

    This code doesn’t require to be called explicitly, it will be applied to all controllers in the configured package. It also will only be applied if the return type of the method is of type Map (no generics check due to type erasure though).

    Even better, it paves the way for future development involving further processing (ordering, paging, etc.).


    There are several ways to share common code in a Spring MVC app, each having different pros and cons. In this post, for this specific use-case, the ResponseBodyAdvice has the most benefits.

    The main taking here is that the more tools one has around one’s toolbelt, the better the final choice. Go explore some tools you don’t know already about: what about reading some documentation today?

    Categories: JavaEE Tags: Spring MVCClean codeDesign
  • Cloud offerings free tier - Amazon vs Google

    As a developer, you’re a pretty important resources for service providers. Without developers, service providers cannot make savings based on scale. Having developers also means higher chances of someone having a killer idea on top of your service, creating even more value. And developers attract more developers.

    In order to achieve that, service providers offer free services. In the Cloud realm, both Google and Amazon have a packaged offer valid for a year. Once the grace period has expired though, access to some limited free services is still available. This post tries to compare free services of those providers side-by-side.

    Common offerings

    Amazon Web Services Google Cloud Platform logo

    NoSQL database



    Cloud Datastore


    Fast and flexible NoSQL database with seamless scalability

    Highly-scalable NoSQL database

    Storage capacity



    # of reads

    25 units


    # of writes

    25 units


    # of deletes




    Mobile Analytics



    Fast, secure mobile app usage analytics

    Fully managed, petabyte scale, analytics data warehouse

    # of events

    100 million

    # of queries

    1 TB




    Cloud Source Repositories


    Highly scalable, managed source control service

    Multiple private Git repositories hosted on Google Cloud Platform

    Storage capacity

    50 GB

    1 GB

    # of active users


    # of requests





    Cloud Functions


    Compute service that runs your code in response to events and automatically manages the compute resources

    A serverless environment to build and connect cloud services with code

    # of requests

    1 million

    2 millions (including HTTP & method invocation)

    Compute time

    3.2 million seconds

    400k GB.seconds, 200k GHz.seconds



    Storage Gateway

    Google Cloud Storage


    Hybrid cloud storage with seamless local integration and optimized data transfer

    Best in class performance, reliability, and pricing for all your storage needs


    100 GB

    5 GB-months of Regional Storage


    • 5k Class A Operations per month
    • 50k Class B Operations per month
    • 1 GB network egress from North America to all region destinations per month (excluding China and Australia)

    Provider-specific offering

    Items are listed here because:

    • Either the competitor doesn’t provide a similar offering e.g. Google Cloud Speech API
    • Or it does but the offering is outside the free tier e.g. Google Compute Engine vs Amazon EC2


    Product Description Details

    Key Management Service

    Managed service that provides easy encryption with administrative controls

    20k free requests per month

    Device Farm

    Test your iOS, Android and FireOS apps on real devices in the AWS cloud

    Free one-time trial of 250 Device Minutes

    Simple Notification Service

    Fast, flexible, fully managed push messaging service

    • 1 million Publishes
    • 100k HTTP/S Deliveries
    • 1k Email Deliveries


    Continuous delivery service for fast and reliable application updates

    1 Active Pipeline per month


    Monitoring for AWS cloud resources and applications

    • 10 Custom Metrics and 10 Alarms
    • 1 million API Requests
    • 5 GB of Log Data Ingestion and 5 GB of Log Data Archive
    • 3 Dashboards with up to 50 Metrics Each per Month

    Simple Email Service

    Cost-effective email service in the Cloud

    • 62k Outbound Messages per month to any recipient when you call Amazon SES from an Amazon EC2 instance directly or through AWS Elastic Beanstalk.
    • 1k Inbound Messages per month

    Simple Queue Service

    Scalable queue for storing messages as they travel between computers

    1 millions requests

    Simple Workflow Service

    Task coordination and state management service for Cloud applications

    • 10k Activity Tasks
    • 30k Workflow-Days
    • 1k Initiated Executions


    Amazon Chime is a modern unified communications service that offers frustration-free meetings with exceptional audio and video quality

    Basic subscription is free to use for as long you’d like


    Fully managed build service that builds and tests code in the cloud

    100 build minutes per month of build.general1.small compute type usage

    Step Functions

    Coordinate components of distributed applications

    4k state transitions per month


    Analyze and debug your applications

    • 100k traces recorded per month
    • 1 million traces scanned or retrieved per month

    Database Migration Service

    Migrate databases with minimal downtime

    • 750 Hours of Amazon DMS Single-AZ dms.t2.micro instance usage
    • 50 GB of included General Purpose (SSD) storage


    Product Description Details

    Google Compute Engine

    Scalable, high-performance virtual machines

    • 1 f1-micro instance per month (US regions only)
    • 30 GB-months HDD, 5 GB-months snapshot
    • 1 GB network egress from North America to all region destinations per month (excluding China and Australia)

    Google App Engine

    Platform for building scalable web applications and mobile backends

    • 28 instance hours per day
    • 5 GB Cloud Storage
    • Shared memcache
    • 1k search operations per day, 10 MB search indexing
    • 100 emails/day

    Cloud Pub/Sub

    A global service for real-time and reliable messaging and streaming data

    10 GB of messages per month

    Container Engine

    One-click container orchestration via Kubernetes clusters, managed by Google

    • Basic cluster of 5 nodes or fewer
    • The basic cluster is free but each node is charged at standard Compute Engine pricing


    Monitoring, logging, and diagnostics for applications on Cloud Platform and AWS

    • 5 GB of logs with 7 day retention
    • Read access API
    • Basic email alerting

    Cloud Vision API

    Label detection, OCR, facial detection and more

    1k units per month

    Cloud Speech API

    Speech to text transcription, the same that powers Google’s own products

    60 minutes per month

    Cloud Natural Language API

    Derive insights from unstructured text using Google machine learning

    5k units per month

    Cloud Shell

    Manage your infrastructure and applications from the command-line in any browser

    Free access to Cloud Shell, including 5 GB of persistent disk storage

    Cloud Container Builder

    Fast, consistent, reliable container builds on Google Cloud Platform

    120 build-minutes per day


    Free services listed above, even if limited compared to the standard version, shouldn’t be overlooked. They can be used for prototyping, having fun with a crazy idea, teaching and/or self-learning. Have fun!

    To go further:

    Categories: Technical Tags: GoogleAmazonfreeCloud
  • Fully configurable mappings for Spring MVC

    Spring Boot logo

    As I wrote some weeks earlier, I’m trying to implement features of the Spring Boot actuator in a non-Boot Spring MVC applications. Developing the endpoints themselves is quite straightforward. Much more challenging, however, is to be able to configure the mapping in a properties file, like in the actuator. This got me to check more closely at how it was done in the current code. This post sums up my “reverse-engineering” attempt around the subject.

    Standard MVC


    In Spring MVC, in a class annotated with the @Controller annotation, methods can be in turn annotated with @RequestMapping. This annotation accepts a value attribute (or alternatively a path one) to define from which path it can be called.

    The path can be fixed e.g. /user but can also accepts variables e.g. /user/{id} filled at runtime. In that case, parameters should can be mapped to method parameters via @PathVariable:

    @RequestMapping(path = "/user/{id}", method = arrayOf(RequestMethod.GET))
    fun getUser(@PathVariable("id") id:String) = repository.findUserById(id)

    While adapted to REST API, this has to important limitations regarding configuration:

    • The pattern is set during development time and does not change afterwards
    • The filling of parameters occurs at runtime


    With the above, mappings in @Controller-annotated classes will get registered during context startup through the DefaultAnnotationHandlerMapping class. Note there’s a default bean of this type registered in the context. This is summed up in the following diagram:

    DefaultAnnotationHandlerMapping sequence diagram

    In essence, the magic applies only to @Controller-annotated classes. Or, to be more strict, quoting the DefaultAnnotationHandlerMapping’s Javadoc:

    Annotated controllers are usually marked with the Controller stereotype at the type level. This is not strictly necessary when RequestMapping is applied at the type level (since such a handler usually implements the org.springframework.web.servlet.mvc.Controller interface). However, Controller is required for detecting RequestMapping annotations at the method level if RequestMapping is not present at the type level.



    Spring Boot actuator allows for configuring the path associated with each endpoint in the application.properties file (or using alternative methods for Boot configuration).

    For example, the metrics endpoint is available by default via the metrics path. But’s it possible to configure a completely different path:


    Also, actuator endpoints are by default accessible directly under the root, but it’s possible to group them under a dedicated sub-context:


    With the above configuration, the metrics endpoint is now available under the /manage/mymetrics.


    Additional actuator endpoints should implements the MvcEndpoint interface. Methods annotated with @RequestMapping will work in the exact same way as for standard controllers above. This is achieved via a dedicated handler mapping, EndpointHandlerMapping in the Spring context.

    HandlerMapping to map Endpoints to URLs via Endpoint.getId(). The semantics of @RequestMapping should be identical to a normal @Controller, but the endpoints should not be annotated as @Controller (otherwise they will be mapped by the normal MVC mechanisms).

    The class hierarchy is the following:

    MvcEndpoint class diagram

    This diagram shows what’s part of Spring Boot and what’s not.


    Actuator endpoints reuse some from the existing Spring MVC code to handle @RequestMapping. It’s done in a dedicated mapping class so as to separate standard MVC controllers and Spring Boot’s actuator endpoint class hierarchy. In order to achieve fully configurable mappings in Spring MVC, this is the part of the code study, to duplicate and to adapt should one wants fully configurable mappings.

    Categories: JavaEE Tags: Spring MVCactuatorSpring Boot
  • Coping with stringly-typed

    UPDATED on March 13, 2017: Add Builder pattern section

    Most developers have strong opinions regarding whether a language should be strongly-typed or weakly-typed, whatever notions they put behind those terms. Some also actively practice stringly-typed programming - mostly without even being aware of it. It happens when most of attributes and parameters of a codebase are String. In this post, I will make use of the following simple snippet as an example:

    public class Person {
        private final String title;
        private final String givenName;
        private final String familyName;
        private final String email;
        public Person(String title, String givenName, String familyName, String email) {
            this.title = title;
            this.givenName = givenName;
            this.familyName = familyName;
            this.email = email;

    The original sin

    The problem with that code is that it’s hard to remember which parameter represents what and in which order they should be passed to the constructor.

    Person person = new Person("[email protected]", "John", "Doe", "Sir");

    In the previous call, the email and the title parameter values were switched. Ooops.

    This is even worse if more than one constructor is available, offering optional parameters:

    public Person(String givenName, String familyName, String email) {
        this(null, givenName, familyName, email);
    Person another = new Person("Sir", "John", "Doe");

    In that case, title was the optional parameter, not email. My bad.

    Solving the problem the OOP way

    Object-Oriented Programming and its advocates have a strong aversion to stringly-typed code for good reasons. Since everything in the world has a specific type, so must it be in the system.

    Let’s rewrite the previous code à la OOP:

    public class Title {
        private final String value;
        public Title(String value) {
        	this.value = value;
    public class GivenName {
        private final String value;
        public FirstName(String value) {
        	this.value = value;
    public class FamilyName {
        private final String value;
        public LastName(String value) {
        	this.value = value;
    public class Email {
        private final String value;
        public Email(String value) {
        	this.value = value;
    public class Person {
        private final Title title;
        private final GivenName givenName;
        private final FamilyName familyName;
        private final Email email;
        public Person(Title title, GivenName givenName, FamilyName familyName, Email email) {
            this.title = title;
            this.givenName = givenName;
            this.familyName = familyName;
            this.email = email;
    Person person = new Person(new Title(null), new FirstName("John"), new LastName("Doe"), new Email("[email protected]"));

    That way drastically limits the possibility of mistakes. The drawback is a large increase in verbosity - which might lead to other bugs.

    Pattern to the rescue

    A common way to tackle this issue in Java is to use the Builder pattern. Let’s introduce a new builder class and rework the code:

    public class Person {
        private String title;
        private String givenName;
        private String familyName;
        private String email;
        private Person() {}
        private void setTitle(String title) {
            this.title = title;
        private void setGivenName(String givenName) {
            this.givenName = givenName;
        private void setFamilyName(String familyName) {
            this.familyName = familyName;
        private void setEmail(String email) {
            this.email = email;
        public static class Builder {
            private Person person;
            public Builder() {
                person = new Person();
            public Builder title(String title) {
                return this;
            public Builder givenName(String givenName) {
                return this;
            public Builder familyName(String familyName) {
                return this;
            public Builder email(String email) {
                return this;
            public Person build() {
                return person;

    Note that in addition to the new builder class, the constructor of the Person class has been set to private. Using the Java language features, this allows only the Builder to create new Person instances. The same is used for the different setters.

    Using this pattern is quite straightforward:

    Person person = new Builder()
                   .email("[email protected]")

    The builder patterns shifts the verbosity from the calling part to the design part. Not a bad trade-off.

    Languages to the rescue

    Verbosity is unfortunately the mark of Java. Some other languages (Kotlin, Scala, etc.) would be much more friendly to this approach, not only for class declarations, but also for object creation.

    Let’s port class declarations to Kotlin:

    class Title(val value: String?)
    class GivenName(val value: String)
    class FamilyName(val value: String)
    class Email(val value: String)
    class Person(val title: Title, val givenName: GivenName, val familyName: FamilyName, val email: Email)

    This is much better, thanks to Kotlin! And now object creation:

    val person = Person(Title(null), GivenName("John"), FamilyName("Doe"), Email("[email protected]"))

    For this, verbosity is only marginally decreased compared to Java.

    Named parameters to the rescue

    OOP fanatics may stop reading there, for their way is not the only one to cope with stringly-typed.

    One alternative is about named parameters, and is incidentally also found in Kotlin. Let’s get back to the original stringly-typed code, port it to Kotlin and use named parameters:

    class Person(val title: String?, val givenName: String, val familyName: String, val email: String)
    val person = Person(title = null, givenName = "John", familyName = "Doe", email = "[email protected]")
    val another = Person(email = "[email protected]", title = "Sir", givenName = "John", familyName = "Doe")

    A benefit of named parameters besides coping with stringly-typed code is that they are order-agnostic when invoking the constructor. Plus, they also play nice with default values:

    class Person(val title: String? = null, val givenName: String, val familyName: String, val email: String? = null)
    val person = Person(givenName = "John", familyName = "Doe")
    val another = Person(title = "Sir", givenName = "John", familyName = "Doe")

    Type aliases to the rescue

    While looking at Kotlin, let’s describe a feature released with 1.1 that might help.

    A type alias is as its name implies a name for an existing type; the type can be a simple type, a collection, a lambda - whatever exists within the type system.

    Let’s create some type aliases in the stringly-typed world:

    typealias Title = String
    typelias GivenName = String
    typealias FamilyName = String
    typealias Email = String
    class Person(val title: Title, val givenName: GivenName, val familyName: FamilyName, val email: Email)
    val person = Person(null, "John", "Doe", "[email protected]")

    The declaration seems more typed. Unfortunately object creation doesn’t bring any betterment.

    Note the main problem of type aliases is that they are just that - aliases: no new type is created so if 2 aliases point to the same type, all 3 are interchangeable with one another.

    Libraries to the rescue

    For the rest of this post, let’s go back to the Java language.

    Twisting the logic a bit, parameters can be validated at runtime instead of compile-time with the help of specific libraries. In particular, the Bean validation library does the job:

    public Person(@Title String title, @GivenName String givenName, @FamilyName String familyName, @Email String email) {
        this.title = title;
        this.givenName = givenName;
        this.familyName = familyName;
        this.email = email;

    Admittedly, it’s not the best solution… but it works.

    Tooling to the rescue

    I have already written about tooling and that it’s as important (if not more) as the language itself.

    Tools fill gaps in languages, while being non-intrusive. The downside is that everyone has to use it (or find a tool with the same feature).

    For example, when I started my career, coding guidelines mandated developers to order methods by alphabetical order in the class file. Nowadays, that would be senseless, as every IDE worth its salt can display the methods of a class in order.

    Likewise, named parameters can be a feature of the IDE, for languages that lack it. In particular, latest versions of IntelliJ IDEA emulates named parameters for the Java language for types that are deemed to generic. The following shows the Person class inside the IDE:


    While proper OOP design is the historical way to cope with stringly-typed code, it also makes it quite verbose and unwieldy in Java. This post describes alternatives, with their specific pros and cons. Each needs to be evaluated in the context of one’s own specific context to decide which one is the best fit.

  • A use-case for Spring component scan

    Regular readers of this blog know I’m a big proponent of the Spring framework, but I’m quite opinionated in the way it should be used. For example, I favor explicit object instantiation and explicit component wiring over self-annotated classes, component scanning and autowiring.


    Though those concepts are used by many Spring developers, my experience has taught me they are not always fully understood. Some explanation is in order.

    Self-annotated classes

    Self-annotated classes are classes which define how they will be instantiated by Spring via annotations on the classes themselves. @Component, @Controller, @Service and @Repository are the usual self-annotated classes found in most Spring projects.

    class MySelfAnnotatedClass

    The main disadvantages of self-annotated classes is the hard coupling between the class and the bean. For example, it’s not possible to instantiate 2 singleton beans of the same class, as in explicit creation. Worse, it also couples the class to the Spring framework itself.

    Note that @Configuration classes are also considered to be self-annotated.

    Component scanning

    Self-annotated classes need to be listed and registered in the context. This can be done explicitly:

    class MyConfig {
        fun myClass() =  MySelfAnnotatedClass()

    However, the most widespread option is to let the Spring framework search for every self-annotated class on the project classpath and register them according to the annotations.

    @Configuration @ComponentScan
    class MyConfig


    Some beans require dependencies in order to be initialized. Wiring the dependency into the dependent bean can be either:

    • explicit: it’s the developer’s responsibility to tell which beans will fulfill the dependency.
    • implicit (or auto): the Spring framework is responsible to provide the dependency. In order to do that, a single bean must be eligible.

    Regarding the second option, please re-read an old post of mine for its related problems.

    Sometimes, however, there’s no avoiding autowiring. When bean Bean1 defined in configuration fragment Config1 depends on bean Bean2 defined in fragment Config2, the only possible injection option is autowiring.

    class Config2 {
        fun bean2() = Bean2()
    class Config1 {
        @Bean @Autowired
        fun bean1(bean2: Bean2) = Bean1(bean2)

    In the above snippet, autowiring is used without self-annotated classes.

    Reinventing the wheel

    This week, I found myself re-implementing Spring Boot’s actuator in a legacy non-Spring Boot application.

    The architecture is dead simple: the HTTP endpoint returns a Java object (or a list of them) serialized through the Jackson library. Every endpoint might return a different object, and each can be serialized using a custom serializer.

    I’ve organized the project in a package-per-endpoint way (as opposed to package-per-layer), and have already provided several endpoints. I’d like people to contribute other endpoints, and I want it to be as simple as possible. In particular, they should only:

    1. Declare controllers
    2. Declare configuration classes
    3. Instantiate Jackson serializers

    The rest should taken care of by generic code written by me.

    The right usage of autowire

    Controllers and configuration classes are easily taken care of by using @ComponentScan on the main configuration class located in the project’s main package. But what about serializers?

    Spring is able to collect all beans of a specific class registed into a context into a list. That means that every package will declare its serializers independently, and common code can take care of the registration:

    @Configuration @EnableWebMvc @ComponentScan
    class WebConfiguration : WebMvcConfigurerAdapter() {
        private lateinit var serializers: List<StdSerializer<*>>
        override fun configureMessageConverters(converters: MutableList<HttpMessageConverter<*>>) {
            converters.add(MappingJackson2HttpMessageConverter().apply {
                objectMapper.registerModule(SimpleModule().apply {
                    serializers.forEach { addSerializer(it) }

    Magic happens on lines 6 and 7 above. This configuration class has already been written, and new packages don’t need to do anything, serializers will be part of the list.

    Here’s an example of such a configuration class, declaring a serializer bean:

    class FooConfiguration {
        fun fooSerializer()  = FooSerializer()
    class FooSerializer : StdSerializer<Foo>(Foo::class.java) {

    Even better, if packages need to be modularized further into full-fledged JARs, this setup will work in the exact same way without any change.


    A better understanding of self-annotated classes, component-scanning and autowiring is beneficial to all Spring developers.

    Moreover, while they have a lot of drawbacks in “standard” beans classe, it’s not only perfectly acceptable but even an advantage to do so within the scope of configuration classes. In projects designed in a package-by-feature way, it improves modularization and decoupling.

    Categories: Development Tags: Springautowiringcomponent scangood practice