Monthly Archives

December 2016

Promise me you won’t use Promise.race

Before we start, if you’re not sure what JavaScript Promises are, read this post. It’s a really great introduction for Promises. Furthermore, the code examples in this post uses Arrow functions, if you are unfamiliar with them, check out this link for an explanation.


My colleague, Erik Timmers, and I often have discussions about programming and related technologies. This blog post is the result of one of those discussions. We discovered that the function Promise.race didn’t exactly do what we expected. So we tested it, figured out how it worked, found out what we thought was wrong, and finally created a version of the Promise.race function that does what we expected. After that we went a little bit further…and added some functionality to the function. Please note that this code shouldn’t be used in production, or at the very least, it should be tested a bit more. We did it “because we could”, but also because we wanted to understand the functionality. If you would like to view, extend, learn from the actual code, the source code is also available on GitHub.

So what’s wrong with Promise.race?

So you’re working on a JavaScript application, and your IntelliJ (because why would you use any other IDE?) autocomplete pops up with the function ‘race’ when you write ‘Promise.’. So without looking at the documentation, what would you expect Promise.race to do?
My first though was, that you can probably pass a few promises to this function and it returns the value of the first promise that resolved. Makes sense right?

Continue Reading

Modify Java 8 final behaviour with Annotations

How I started this project

Some time ago I went to a Meetup session Death To Null by Ties van de Ven from JDriven. During the presentation it became clear that it wasnt so much about null checks and NullPointerExceptions but more about Immutability and how it can help keep your software free of bugs and NullPointerExceptions. One of the statements that got me thinking was (something along the lines of): Java chose the wrong default. Instead of making everything explicitly final when we want an immutable variable, everything should be implicitly final unless the developer makes it explicitly mutable.
Not knowing that much about the implementation of annotations I thought it would be fun to try to write an annotation which would do exactly that. The first bump I encountered is that annotations cannot modify the programmers source code, or the classes generated from this source code; they can generate new sources or validate code. This quickly turned my attention to project Lombok which does that already. If you use project Lombok for the generation of getters and setters these never show up in your source code. How can your IDE still hint at the existence of the getters and setters?

It turns out that the Java compiler is an iterative process. First the compiler parses your source code into something which is called an AST or Abstract Syntax Tree. Then annotation processors are run to generate extra sources or do some extra validation based on your annotations. Compilation errors, such as invalid classes or invalid method calls, are done in phase 3. If, however, an annotation processor generates new sources, the compiler repeats step 1 and 2 before going to step 3.

Project Lombok, and my proof of concept, will use a bit of a hack. Instead of generating new sources with the annotation processor, it modifies the generated AST. This will allow the processor to change the code without touching the source code or the byte code.

A more detailed explanation can be found here. It is a bit dated, but informative.

Building a PoC

For my proof of concept Ive decided to create a new maven project. It will have two sub projects, one of them contains the annotation itself and the processor which will process it, the other one contains a test class which uses the annotation.

Continue Reading