Pros and cons of JEP 286

Pros and cons of JEP 286

A couple of weeks ago a new JDK Enhancement Proposal (JEP) has been published: JEP 286

It proposes ‘var’ and possible also ‘val’ as a way to declare local variables. This means that for local variables you don’t need to specify the type of your variable when it can be safely infered.

Some examples:

    // Before:
    int ten = 10;
    List<String> list = new ArrayList<>();

    // After
    var ten = 10;    // infers int
    var list = new ArrayList<String>();  // infers ArrayList<String>

Personally I’m not convinced this is a good idea for Java, but OTOH some of my colleagues and co-workers are very happy with the proposal.

Let’s look at some of the pros and cons of this proposal.

Pro: Less typing!

There is one obvious pro: Less typing.

‘var’ is just three characters, while most other local variables type names are much longer.

Instead of typing int, List, Person or SpringObjectFactoryManagerTemplateProxyDelagate you just have var.

    // Instead of:
    List<Integer> myList = someMethod();

    // You can now have:
    var myList = someMethod();

    // We saved 10 keystrokes! (<- probably less if you know shortcuts in your IDE)

Con: Readability

The biggest advantage of Java over other languages is the readability. The language Java is a bit verbose, but this is actually a good thing when it comes to reading the code.

Code is read more than it is written

Consider the following:

    var myVariable = dependency.calculateSomething();

What is the type of myVariable? When you are writing the code, you probably have a good idea why you called dependency and what you receive as return value.

But when you are reading the code, there is no way of knowing what myVariable is… you probably need your IDE to tell you, or look at the code of the dependency.

I personally think this is a con regarding the JEP. I’d rather have a verbose language where the IDE helps me with autocomplete and hide things… than having a language that needs an IDE to help me makes sense of the code.

Pro: Adding var doesn’t break anything

Some peope think (and argue) that adding this feature breaks backwards compatibility (because of the new keyword).

But this is not true!

When ‘var’ gets added it won’t be a keyword, it’ll be a ‘reserved type name’. This means that the following code for example would be working just fine:

    // this compiles just fine:
    var var = "var";

Con: RHS versus LHS

This JEP focusses on the LHS (left-hand side) declaration by removing the need to specify a type. But recently, in Java 7, Java has introduced the diamond operator to eliminate verbosity in the RHS (right-hand side) declaration. With JEP 286, these two collide:

    // Before Java 7 'diamond operator':
    List<Integer> numbers = new ArrayList<Integer>();

    // With Java 7 'diamond operator', removing generic type on RHS:
    List<Integer> numbers = new ArrayList<>();

    // With JEP 286, we need to add the generic type again at the RHS...
    var numbers = new ArrayList<Integer>();

    // Java, make up your mind!

Pro and con: Refactoring

Some people have argued that, after JEP 286, refactoring can become easier. Look at the following, silly, example:

    public boolean hasClosed() {
        var list = getSomeList();
        for(var item : list) {
        	if(item.isClosed()) {
        		return true;
        return false;

No matter what getSomeList() returns, it should work as long as it has the method isClosed. I think this is a weird example, because normally you would define an interface with isClosed and every class that implements this interface can be replaced/refactored as well.

There is a counter argument that can be made, refactoring can also be dangerous with JEP 286, look at this (crafted) example:

    var answer = SomeCode.generate();
    System.out.println(answer + 42);

As long as the method generate returns a number the code works fine. But when someone changes the method to return an object or a String, it stops working without failing compilation. This argument however seems valid, but it would also break it you would have inlined the call to ‘System.out.println(SomeCode.generate() + 2);’.

This might make the problem a bit harder and more widespread. I believe there are more cases this can go wrong.

Try it out for yourself

The best way to get a feel for JEP 286 is just to try it out yourself!

There is a pre-compiled version of JDK-9 with JEP availabe for download at the website: iteratrlearning.


After looking at a lot of examples I’m still not convinced that JEP 286 is good nor bad. It can go either way. There are some good pros but also quite a lot of cons.

When discussing this JEP with co-workers and colleagues I often get the following reply:

The arguments you’re using have been used when C# adopted var/val, stop complaining, they did it.

But did you know most coding guidelines for C# warn you for using ‘var’?

Just read these guidelines from Microsoft:

  • Do not use var when the type is not apparent from the right side of the assignment.
  • Do not rely on the variable name to specify the type of the variable. It might not be correct.
  • Avoid the use of var in place of dynamic.
  • Use implicit typing to determine the type of the loop variable in for and foreach loops.

This, combined with readability, makes me lean towards a no for JEP 286 right now.

How about you? Leave a comment!

JShell API, design problems?

JShell API, design problems?

This weekend I continued working my project making a Java REPL adventure game that teaches the basics of programming (in Java). One main goal of starting this project was to get a better understanding of the JShell API, not just the tool. I’ve used the JDK 9 JShell command line tool before, and it worked great. But there is also a big API behind it you can programatically use.

Let me show you how this works:

        JShell shell = JShell.create();
        List<SnippetEvent> events = shell.eval("int i = 10;");

What have we done here? Well first we’ve created an instance of the JShell. This is just like starting the command line tool. Now we can call the eval() function to evaluate Java code. As a result you receive so called SnippetEvents, these are classes containing the information about what happened. Let’s see what the code above returns:

        for(SnippetEvent event : events) {

        //Output: SnippetEvent(snippet=Snippet:VariableKey(i)#1-int i = 10;,previousStatus=NONEXISTENT,status=VALID,isSignatureChange=true,causeSnippetnullvalue=10)

There is quite some information in there, the event contains the actual ‘snippet’, the piece of code that was executed. Also there is a previous state, status and some other information. This is where the JShell API starts to feel weird to me. To get the Snippet from the SnippetEvent we can call the following method:

        SnippetEvent event = events.get(0);

        // To get the information, we call snippet (not getSnippet()):
        Snippet snippet = event.snippet();

        // Next we cast our snippet to the correct subclass:
        VarSnippet vSnippet = (VarSnippet) snippet;

        // Now we can retrieve information, for example the type we've created:

        //Output: int

        // We can also get the 'value' of the SnippetEvent:

        //Output: 10

There are a couple of points I don’t like about the current JShell API design here:

  • Why are the methods to get information called .snippet() and .typeName(), why not getSnippet() and getTypeName()?
  • Why is the result of vSnippet.typeName() a String?
  • Why is the result of event.value() a String? Didn’t we have an ‘int’?

First the question about the method names. In all of the JDK code they seem to be using the bean-specification, where you have getMethods() for getting and setMethod(…) for setting. I’m not sure why this isn’t the case for the JShell API? Is this a new way Oracle is designing their API’s? Do other new JDK API’s have the same syntax?

Next is the question regarding the usage of Strings. Why is the value() a String when we’ve clearly made something an int? Even worse, let’s create something that is not a primitive:

        List<SnippetEvent> events = shell.eval("jdk.jshell.JShell.create();");

        //Output: jdk.jshell.JShell@4cc0edeb

It is even worse, the only result we get from event.value() is a String and it is clearly just the .toString() of the actual backing object. For this API I would love to see it returning the actual object instead. I understand the JShell tool uses String’s and communicates the toString(), but shouldn’t the API be more general? Or am I missing something here?

Anyway, this is exactly why more people should try these API’s and share the feedback! Mail your feedback and suggestions to the mailing list.

What do you think? Please leave a comment below, or… even better, share your thoughts on the mailing list

Fantasy names using Java JShell

Fantasy names using Java JShell

I’ve been a big fan of the Java JShell from the early beginning. I was even the first one on the mailing list besides the people from Oracle. I’m working on a weekend/side project involving JavaFX and JShell API now for a couple of days and something was bothering me.

The project I’m working on is targetted at teaching kids to learn Java Programming in a fun way. But automaticly generated variable names called $1, $2, $3 etc are not ‘fun’ enough! Luckily I found the following method in the API:

JShell shell = JShell.builder()
                .tempVariableNameGenerator(new CustomNameGenerator())

The name generator has to implement Supplier<String>, with a single method get(), very easy! The generator I’ve made generates semi-random fantasy character names. This is what I’ve ended up with:

-> 10 + 10
|  Expression value is: 20
|    assigned to temporary variable baiduth of type int

-> baiduth * 2
|  Expression value is: 40
|    assigned to temporary variable bleibriss of type int

-> System.out.println(bleibriss + baiduth)


Much better! If you’re interested in the project I’m working on, teaching kids Java with the JShell API and JavaFX, keep an eye out. When I have something worth showing I’ll push it to GitHub so everyone can enjoy it!

Getting to grips with Gatling: Custom Feeder

Getting to grips with Gatling: Custom Feeder

About a year ago someone on my current project did an initial setup of Gatling. This is a performance/stress test tool written in Scala, it is easy to use but very powerful. The basic idea is that you write the test scenario’s in code, the same way as you would create integration/unit tests. The advantage is that the resulting tests are easy to expand, maintain and you’ve got everything under version control.

One very powerful feature Gatling has is the Recorder. It is an application you can launch and it acts like a proxy server. Being a proxy server it can record and log all the calls you do to an application. Without writing any code it can automatically create a stress test!

But in my case someone has already created a scenario for me.

Basic Example

As a programmer it can be a bit daunting when you encounter a ‘foreign language’, in this case Scala. Fear not though, it is very easy to read, extend and write Gatling tests. This is the scenario I started with today:

class OurSimulation extends Simulation {

  // Define some basic HTTP protocol settings:
  val baseHttpProtocol = http
    .acceptHeader( """*/*""")
    .acceptEncodingHeader( """gzip,deflate""")
    .acceptLanguageHeader( """nl-NL,nl;q=0.8,en-US;q=0.6,en;q=0.4""")
    .contentTypeHeader( """text/xml""")
    .userAgentHeader( """Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36""")

  // Define a variables that is inserted into the SOAP template:
  val incrementalId = new AtomicInteger

  // Define the scenario, read from CSV file, add additional variable to the session and post to OurEndpoint:
  val scn = scenario("Our scenario")
    .exec(session => session.set("idField", incrementalId.getAndIncrement))

object OurEndpoint {

  def post(soapMessage: String) = exec(http("RequestName")

class OurSimulationLocal extends OurSimulation {

  // The instance we want to run, against localhost (we also have these for other servers)
  val httpProtocol = baseHttpProtocol.baseURL("http://localhost:1234")

  // Setup the test, ramp up 10 users over a period of 20 seconds
  setUp(scn.inject(rampUsers(10) over (20 seconds))).protocols(httpProtocol)

The SoapMessageTemplate.txt is just a plain text file containing one SOAP call, instead of data it contains tags like: ${field1}. There is also data.csv which is a CSV file with the field names in the first row, comma separated values in the following rows. The tags in the SOAP call get replaced by the values from the selected CSV row.

There is probably nothing more I need to explain, the code reads like it should. The main startingpoint is OurSimulationLocal, this class sets up the Simulation (using setUp()). The Simulation is contructed in the OurSimulation class, for each call it takes the ‘next’ value from the CSV, adds one additional field and posts the message to OurEndpoint, finally it checks for a 200 reply.

Custom Feeder

Instead of having a big list of different options in a CSV file, my task for today was to make a custom Feeder. It is the class that provides data as input for the SOAP messages. We want to have some random data that still makes sense to the application, based on some averages.

It looked pretty hard to do, not having programmed a lot of Scala. In the end it was a breeze! The only thing that bugs me is that there are so many different ways to write your code in Scala. I’m not experienced enough yet to know if it ‘reads’ like proper Scala code, I don’t yet know what ‘good’ and ‘bad’ code looks like.

object MyFeeder {

  val random = new Random()

  def apply():  Feeder[String] = {
      ("name", Random.alphanumeric.take(5).mkString.toUpperCase),
      ("country", (if (random.nextDouble() <= percentageBuitenlands) "B" else "NL"))

class OurSimulation extends Simulation {

  //... snip ....

  // The same scenario, now using our own feeder:
  val feeder = MyFeeder()

  val scn = scenario("Our scenario")
    .exec(session => session.set("idField", incrementalId.getAndIncrement))

Writing a custom feeder is pretty easy to do. The apply() function creates an instance of a Feeder[String] which in turn returns a Map containing [String, String] key value pairs. These are then used to fill the SOAP template!

Of course the real thing I build today is a bit larger and more complex, but the code is basically the same!

Keep the Force asleep

Keep the Force asleep

At the moment it is very hard for an online nerd on Twitter. Star Wars ep 7: The Force Awakens has been released into the wild and most of us haven’t seen it yet. But luckely there is a solution, I’ve created a handy bookmarklet.

A bookmarklet is a piece of Javascript code that you can add as a bookmark. When you are on a certain website (like Twitter) you can press the bookmarklet and the Javascript is executed. The bookmarklet code I’m using has been created using this great website: DeClutter Twitter and it removes most Star Wars related tweets from your timeline!


Just drag this bookmarklet ForceFilter to the bookmark section of your browser. Next time you open Twitter, quickly press the bookmarklet before reading.

The code

Below is the (generated) code, again, made by DeClutter Twitter (all credits belong there):


  function declutter() {
    // Remove tweets containing these terms:
    var rk=['star wars', 'the empire', 'the rebellion', 'han solo', 'theforceawakens', 'jar jar', 'kylo ren', 'rey', 'finn', 'poe dameron', 'xwing', 'deathstar', 'c-3po', 'r2d2', 'jedi', 'darth', 'sith', 'leia'];

    // Twitter timeline entries have class "stream-item" - loop through them, 
    // removing those that match blacklisted term
    $.each($(''), function() {
        var c = $(this).html(); 
        var p = $(this); 
        // Iterate through the keywords, removing the parent element 
        // where a match is found
        $.each(rk, function(i, v) { 
            // Lower-case the text so case issues don't trip us up
            if(c.toLowerCase().indexOf(v.toLowerCase()) > 0) {

Google Guava: Range with LocalDate

Google Guava: Range with LocalDate

This afternoon I was working on implementing a user story with (JodaTime) LocalDate ranges. The problem? I needed to represent a lot of periods, in days. The thing I needed to check: Is a certain LocalDate contained in this period.

First I started looking at JodaTime itself, it has support for Interval(s). But there is a ‘problem’, Interval is based around ReadableInstants, and LocalDate is a ReadablePartial, not a ReadableInstant! So to make my code work I had to do the following:

    // Use two LocalDate instances to create an Interval (the JodaTime way)
    private Interval createInterval(LocalDate fromDate, LocalDate toDate) {
        DateTime fromDateTime = fromDate.toDateTimeAtStartOfDay();
        DateTime toDateTime = toDate.toDateTimeAtStartOfDay();
        return new Interval(fromDateTime, toDateTime);

    // Now to check an interval I needed to call:

It works, sure, but the conversion to ReadableInstant with toDateTimeAtStartOfDay kind of bugged me. But luckely Google Guava has something to make the code much cleaner: Ranges

Using Range made the code much smaller and easier to read:

    // Use two LocalDate instances to create an Range (the Google Guava way)
    private Range<LocalDate> createRange(LocalDate fromDate, LocalDate toDate) {
        return Range.closedOpen(fromDate, toDate);

    // To check:

I really love using Google Guava, it provides solutions for a lot of common programming challenges. Not only that, their API is very very clean and skillfully designed. The use of open/closed in is very handy and makes it easy to think about corner cases.

Makeblock, robots for kids (and adults)

Makeblock, robots for kids (and adults)

When I left the Port of Rotterdam (over a year ago) as consultant/software developer I got a lot of cool gifts. Amongst the gifts was a small blue box from Makeblock, called the ‘robot starter kit’. It was put away on my desk and sadly I’d forgotten about it. But recently a colleague of mine showed us the robot his daughter made. She got a similar robot from Makeblock for her birthday and it ‘became her new best friend’. He asked her if he could borrow the robot for one day and show it to us at work, she reluctantly said yes.

When I got home I suddenly remembered the blue box I had laying around in the corner of my desk. I decided to show it to my 3 year old daughter. She loved the idea of having her own little robot in her room. Searching online I couldn’t find a suggested appropriate age for these robots so I figured: if she wants to try, just go for it!

Starting the assembly of the robot (bananas not included)

She immediately jumped in and started handling the screwdriver like a pro. I was amazed to see the dedication, concentration and dexterity, when I was younger I had none of the three. In about half an hour we had the base constructed and she lost interest for a little while. I decided to continue alone for 10 minutes and the only thing left to do was assembling the tank tracks. So I called her over and we decided to hold a little race, 20 rubber pieces for me, 20 for her. It was a pain to assemble, but by introducing a small competition I only had one track to assemble, she did the other one all by herself.

The cool thing about these robots is their simplicity: The frame goes together quickly with a couple of screws and removable rivets. All the electronics are connected by RJ25 (telephone) jacks. The kit I got had an IR-receiver (+ remote) and ultrasonic sensor. The remote is great because she is too young for programming. The moment you put it together and place the batteries you can start driving the robot around. She loved it, look at her proud smug face:

I've build a robot, now what?

Next thing I’ll do it to teach it how to dance! Then I’ll teach it how to clean my room.

That evening, when she was vast asleep, I started working on the programming. The main board in this robot is compatible with an Arduino. To program the robot you connect it to your laptop using USB and fire up the Arduino IDE with the Makeblock library. Commands are very simple to use, for example reading the distance sensor is: ‘ultraSensor.distanceCm()’. That night, when my daughter was sleeping, I added an automatic drive-mode so the robot would drive around randomly avoiding all obstacles with help of the ultrasonic sensor. When she woke up I told her ‘go ahead and hit the 0 on the remote!’. She was blown away, her little robot had grown a mind of its own!

When she is a bit older we’re going to try out the mBlock/Scratch plugin. Scratch (for those unfamiliar) is an environment where you can visually program with graphical blocks. It is a drag and drop environment and works very well as a first programming tool for kids. It is also something we regularly use at Devoxx4Kids

Things I like about the Makeblock robot:

  • Easy to assemble (even for a 3yo)
  • Instructions had a lot of images
  • Fun to program

And of course, it isn’t perfect, things I didn’t like:

  • Should come with a CR2025 coin cell battery for the remote (I had to race to the store to get one)
  • Instructions only had images, nothing else (bit too brief)

Nontheless: Every parent should buy one!

Hacking a broken Roomba (with Raspberry Pi)

Hacking a broken Roomba (with Raspberry Pi)

roomba-googledag Every couple of weeks we organize a hack-day at work. Being a (Java) software consulting company we usually work on exploring new Java frameworks or we contribute to open source projects. But more and more we step out of just software and bring Raspberry Pi’s and other hardware. Another example where we hacked on hardware is playing with Software Defined Radio (SDR), my colleague Bert Jan did a talk about this at Devoxx 2015.

Broken Roomba

A couple of days before our last hack-day my wife was carrying our old ‘broken’ Roomba vacuuming robot. Most vacuuming parts were worn down and the front wheel keeps dropping out of its socket. She was going to throw a robot out! I can’t let this happen, I have to save the poor bastard.

So I started to do a little research. I’d heard about the Roomba Create before. It is a STEM-version of their vacuuming robot, for hacking purposes. It doesn’t have the cleaning parts, instead of has more connectors, made especially to be hacked/improved, it is the perfect base for your own little robot! I was very pleased to find that even my 500-series Roomba has a hidden mini-DIN connector that allows serial communication. iRobot provides a full listing of all the possible commands and outputs, which is a great thing!

Connecting a Raspberry Pi

Here is what my idea was: Take a mini-DIN cable, connect it to a Raspberry Pi and drive the Roomba myself! But I quickly run into two problems:

  • How do I connect the Raspberry Pi to a DIN cable?
  • How do I power the Raspberry Pi?

After some research I was able to solve both of the problems.

Mini-DIN to Raspberry Pi

After some research I found out some good and some bad news. First the good news, the Raspberry Pi has an UART TX and RX pin. These can be used to communicate with the Roomba without any effort.

The bad news? The Roomba has logic pins that have 0-5v and the Raspberry Pi has 0-3.3v. You can’t directly combine the two together or you’ll risk blowing a fuse on the Raspberry Pi. There is however a pretty simple solution, that is to use a Logic Level Converter. This is a small board that you give 3.3v + GND on one end, 5v + GND on the other end. Now it has four logic pins left that can be used to connect 3.3v logic to 5v logic bi-directionally.

So with a bit of creative freeform-soldering I ended up with the following extension to my Raspberry Pi:


The only thing left to do next is to connect the right DIN-wires to the Raspberry Pi. But luckely the documentation provided by iRobot had very clear images showing all the mini-DIN pins and what they do.

Powering the Raspberry Pi

The next challenge was actually power the Raspberry Pi. The Roomba has a battery pack, 16-17v, so that would be perfect. This seemed to be an easy challenge initially because the DIN-cable also provides access to the battery pack. But just before I hooked the Raspberry Pi to the (unregulated) battery wires of the DIN cable I found that there are actually some fuses between the DIN connector and the battery pack. The Raspberry Pi would draw too much current for these fuses!

Next I opened up the Roomba completely. Just below the ‘Dock’ button are two big pads directly connected to the battery pack. I soldered two wires to these pads. This gave me 16v (without the fuses) to power the Raspberry Pi. But how do I step this down to the 5v needed by the Raspberry Pi? I connected the wires to a UBEC and soldered a mini-USB cable to the output. Connected to the Raspberry Pi and… it worked like a charm!

Programming the Roomba

When we connect the Raspberry Pi to the Roomba using the DIN cable, it starts to play weird error-beeps. This is because by default the Raspberry Pi writes all console output to the serial connections (!). Please read this link to disable it.

Like I said, the serial commands needed to drive the Roomba are perfectly documented. Using the GNU RXTX library (RXTXcomm.jar) we can write the following Java code:

    // On the Raspberry Pi the Serial communication pins are connected to /dev/ttyAMA0
    CommPortIdentifier portIdentifier = CommPortIdentifier.getPortIdentifier("/dev/ttyAMA0");
    if( portIdentifier.isCurrentlyOwned() ) {
        System.out.println( "Error: Port is currently in use" );
    } else {
        CommPort commPort =, 2000);

        if( commPort instanceof SerialPort) {
            SerialPort serialPort = ( SerialPort )commPort;
                    SerialPort.PARITY_NONE );

            InputStream in = serialPort.getInputStream();
            OutputStream out = serialPort.getOutputStream();

            ( new Thread( new SerialReader( in ) ) ).start();
            ( new Thread( new SerialWriter( out ) ) ).start();

Now we can send commands to the OutputStream, like documented. Using this I was able to drive the Roomba through SSH to the Raspberry Pi from my laptop!

For example, we can do the following:

    // Write imperial march as song '0':
    write(out, 140, 0, 9, 57, 30, 57, 30, 57, 30, 53, 20, 60, 10, 57, 30, 53, 20, 60, 10, 57, 45);
    // Play song '0':
    write(out, 141, 0);
    ... snip ...

    private void write(OutputStream out, int... data) throws IOException {
        // Sigh, unsigned Java:
        byte[] output = new byte[data.length];
        for(int i = 0; i < data.length; i++) {
            output[i] = (byte)(data[i]&0xFF);

If you remove the DIN cable, it’ll still function perfectly as cleaning robot. So now I have a Star Wars bot to program during the day, and a cleaning robot at night.

Happy hacking!

If you want to build software...

If you want to build software...

Yesterday I heard a great quote:

If you want to build a ship, don’t drum up people to collect wood and don’t assign them tasks and work, but rather teach them to long for the endless immensity of the sea. -Antoine de Saint-Exupery

To the moon

The modern version of this quote might be: Think about the people who helped build the Saturn rockets that took us to the moon with the Apollo missions. They didn’t work on those projects because it was their job and people payed them to do it. They didn’t just follow tasks. They worked on the project because they loved to be part of this amazing voyage. Every single NASA employee is in love with space and space exploration and they do their absolute best to be part of it.

Software development

This should be the same for (Agile) software development:
Don’t hire programmers and give them tasks, tell them about what you want to achieve! Enthusiasm is contagious, it is the perfect catalyst to boost productivity. When people are hired to do tasks, they do the tasks, nothing more, nothing less. When people are hired to reach for a certain goal they’ll express creativity and ingenuity. They will suggest improvements and you’ll end up with a much (MUCH) better product.

The most discriminating JUG in the world

The most discriminating JUG in the world

About a week ago I was talking to a colleague about the lack of female Java programmers, especially here in Western Europe. We came to this topic after hearing that at Devoxx Morocco almost a third of the attendees was female, great news! The conclusion? Some of my friends are running the most discriminating JUG in the world.

Here, in the Netherlands, we have just two big JUG’s (Java User Groups). There is the NLJUG, which covers the entire country and organises the J-Fall conference amongst other things, almost all Java coders in the Netherlands are a member. There is also JDuchess, the female JUG. They organise meetings with fellow female coders and help them to connect with other (female) coders around the globe, they also hold regular meetups, also internationally at conferences and they are doing an awesome job hosting several Devoxx4Kids events per year. The JDuchess have been awarded (rightly so) multiple times for their effort in bringing more gender equality in the Java world.


When you think about that… surprisingly, JDuchess is the most discriminating JUG in the world! Of all the JUGs I know, it is the only one I’ll never be allowed to join (unless I undergo a sex-change perhaps). It is the only JUG in the world that is filtering members based on gender. And in my opinion, that is a problem.

So, why is this a problem? It is just a group of female coders that want to hang out and help each other! Well, first of all, don’t get me wrong. Again, I love what the JDuchess are doing for the Java community, I know some of them pretty well personally and they are all very nice and have the best intention!

But… if you feel like you are not welcome in your local JUG as female coder and you want to do something about this. Please don’t start a ‘female only’-JUG, start a JUG where everyone is welcome and like-minded! If you want to have more equality and integration you shouldn’t be organising your own discriminating group. We need to have male and female coders to work together to solve the gender equality problems!

Also, I must mention: JDuchess was never about equality or discrimination. It wasn’t born out of frustration as mentioned above. It was just a way for female coders (who often felt lonely during conferences) to connect and have more ‘female-oriented’ conversations with each other.

JDuke, the JUG of testosterone

Imagine this, someone starts JDuke: the male only JUG! We do cool meetings, share experiences with other men! On conferences we proudly wear our male-only badge, because we are MEN! Next to attending sessions and giving talks at conferences we also have our own meetups, just for men of course, and we all go out for dinner, together. Everybody is welcome at our JUG, as long as you have a … are a dude.

The world would probably explode, how dare we do something so discriminating? But remember, this is exactly what the JDuchess have been doing all the time. Except, what they do isn’t questioned, it is applauded instead. Probably because they are (still) a minority?

So… you are jealous?

Yes! I want to join JDuchess too! If I was a female I would totally love being part of their JUG.

But, as a male, I too want to share experiences with everyone, I too want to discuss the topic of equality. There should be no need in the world for a female JUG (which apparently there still is)! All the JUGs should be as open and inviting as the JDuchess, I’ve never seen a JUG so active and welcoming as them. They are an example for other JUGs… except their discriminating admission policy of course. Gender should not matter, it is all about having mutually shared interest.

JavaOne 2015 and Devoxx 2015

JavaOne 2015 and Devoxx 2015

The last couple of weeks have been really busy for me. I’ve been to San Francisco for JavaOne 2015 (the official Java conference). After that I had just a week to recover and travelled to Antwerp in Belgium for Devoxx 2015 (the largest community driven conference).


At both conferences I had the pleasure to talk about different subjects. From fun/informal Ignite sessions about Skynet and Joggling to hosting a Java Pub Quiz and a live-coding introduction to JShell the new REPL (read-eval-print loop) that will be available in Java 9.

Here is a video of the live-coding session:


One major announcement at Devoxx 2015 is that Stephan Janssen (Devoxx organizer/godfather) will stop with Parleys. Instead all the talks will be freely available on the Devoxx 2015 YouTube channel. This brings all the excellent content from the conference to the entire community, for free!

If you are curious on how this video is recorded and what Devoxx looks like behind the scenes, check out the Devoxx Live video I made with Stephan Janssen:

Devoxx Live is a new concept, instead of just providing all the talks we want to show you the other side of Devoxx: the hallway. This is where you meet people, talk to the sponsors, experience things like drone racing and hoverboard/monowheeling.

JavaOne has also posted a lot of sessions to YouTube, but instead of cutting everything into nice little videos they’ve decided to upload just the raw streams of the entire day. Luckely there is always ‘the community’, in this case, the people over at reddit created a nice list with video-deeplinks to the appropriate talks: JavaOne 2015 talks on reddit


The first keynote at JavaOne wasn’t very interesting, most conferences just want to sell it to sponsors and don’t have any good content. The second keynote at JavaOne was the ‘community keynote’. During a theatrical play Stephen Chin took us back in time (and into the future) to keep Duke from destroying San Francisco. It was entertaining, but could really use a better screenwriter (that ending, *sigh*), but it did have a powerfull message: teaching and children are the future. This was also pretty visible at JavaOne4Kids (where I did a session with my colleagues), during this event hundreds of kids got introduced to programming and robotics.

The keynotes at Devoxx were (IMHO) much better, during the first keynote we heard Mark Reinhold talk about project Jigsaw and after that one of my heroes took the stage: professor Lawrance Krauss. Instead of focussing on the last 20 years of Java (which all conferences do) we took a step back and looked at the origins of our universe and life. He talked about the Large Hadron Collider (LHC) and gravitational wave observatories. The closing keynote at Devoxx was done by Stephen Chin and included a lot of video footage from an interview he’s done with James Gosling (the father of Java), this was fun too!

Best sessions

If you’ve seen the top 10-list of highest votes at Devoxx 2015 there is one name you can’t mention: Venkat Subramaniam. He brings live-coding to a new level, all of his talks are entertaining and interesting. The top 4 talks bore his name three times.

Another thing I really enjoyed was the series of talks by Mark Reinhold/Alan Bateman (and at JavaOne also Alex Buckley) on the Jigsaw project. If you want to spend just an hour learning about this topic, I highy suggest watching: Advanced Modular Development. This talk covers everything you’ll need to know once Java 9 is released and you’re going to use it.

Random remarks

JavaOne: This was the first time I’ve been there since Oracle aquired Sun. I really enjoyed the conference although the Hilton & Parc 55 location isn’t as convenient as Moscone.

JavaOne: I really liked having Duke’s Café to talk to all of my conference-buddies. Also: If you ever see someone alone at a conference, walk there and say hello. Being at such a huge conference can (surprisingly) be a very lonely experience. Most programmers aren’t very outgoing, me included, but I’ve started forcing myself to talk to people that look like other introverts that might be lonely. I’ve never had a bad experience talking to people, only fun times!

Devoxx: It is (for me) the best Java conference in the world, the quality of the talks was very high again. The atmosphere was awesome. And I’m not just saying this because I volunteer during the conference :-)

Microservices: Creationism versus Evolutionism

Microservices: Creationism versus Evolutionism

This morning a friend (@vgrgic) tweeted the following quote from Martin Fowler:

“So if you can keep your system simple enough to avoid the need for microservices: do.”

This is absolutely true I think, microservices are far from the silver bullet some people want you to believe. They do have a place in software architecture obviously, but there is always a ‘it depends’.


A lot of microservices ‘experts’ I’ve met are creationists. When they start designing an application (the last two years), they break the requirements down into pieces. Once they start coding they instantly create small services and connect them. But in my experience, this has a major drawback. When doing this, you’ll need to make quite a lot of assumptions upfront on what the future of the service will hold and how it will grow. Once you’ve created small services they have very strong boundaries, those boundaries really dictate and limit how your application can and will grow. This can work well, only if all your assumptions turn out to be true, but really, how often does that happen?


I’ve labelled myself as a design evolutionist. Always start with a monolith. Properly separate the concerns in your code, keep it really clean and tidy. Always be aware of what each piece of code does and if it belongs where you just wrote it. In the best scenario, you’ll end up with a simple, well build, working monolith! This is also what Martin Fowler describes in his piece on MicroservicePremium. There is a point where the monolith becomes a burden to manage. Once you reach that point, and you’ve payed proper attention to the separation of concerns, it should be trivial to cut loose a well defined microservice from your code.

Rant about the hype

Warning: The following paragraph is full of nonsense.

Until recently I couldn’t understand the microservices hype. Why is it suddenly this popular? But recently I’ve seen the light. I now know why so many people like it. Microservices has a wide appeal for many wrong reasons.

  1. Architects (like me) like it because it solves one kind of problem really well, managing and maintaining a huge application.
  2. The DevOps community likes it because they have a lot to do when you have heaps of services.
  3. Large SOA/ESB companies like it, they almost went bankrupt and out of fashion, but now they can sell their crappy tooling again as it ‘enables microservices’.
  4. The OSGi community likes it, they too can use the term microservices to sell OSGi tooling and knowledge.
  5. Application servers like it because they can create tooling to enable microservices.
  6. Monitoring companies found a new gap in the market, they can now sell microservices monitoring tools…
  7. Etc etc et fucking cetera!

Stop the conference committees?

Stop the conference committees?

In this post I’ll try to convince you that all the conferences are doing it wrong. JavaOne, Devoxx, and all other conferences should stop using conference program committees to select their speakers, there is a much better way.

Call for Papers

Some of you know I enjoy speaking in public and I’ve done so at many conferences. To get selected to speak at a conference you’ll need to supply a ‘paper’ to the Call for Papers (CfP). In this paper you outline the content of your talk and provide some information about yourself as speaker.

Once all these papers are submitted some people from the community will look at all the proposals and they have the daunting task of selecting the right ones. This is very hard to do, I know this for a fact since I’ve been on several program committees, for example for J-Fall.

The honor from hell

When I got asked to be on a program committee it felt like a real honor and a lot of fun. But in reality it is a painstaking task! You’ll get a lot of papers to review, sometimes up to or over a hundred. And you have to rate them, all of them! Once you are halfway through you can’t really give an honest rating compared to the first papers you’ve reviewed, plainly because you’ve seen too much and can’t remember most of them. There is something very wrong about this system.


Another popular topic these days is gender bias. Until recently in IT a lot of these program committees were dominated by males. Research has shown that an all-male committee is much more likely to pick male speakers than female speakers for example. This is why currently most conferences try to pick a committee that is as mixed as possible. But is that really solving the problem?


A third problem is the flooding. Some people have found out that submitting papers has a bit of chance/luck to it. If you write down the right words people will fall in love with it and you get picked. So instead of submitting one paper, they’ll just submit five or even ten papers, sometimes about the same topic but with other buzzwords. This actually improves their chances of getting in instead of getting a penalty!

Telescope Time assignment

This brings me to a Numberphile YouTube video called: Telescope Time without Tears. It turns out they had exactly the same problems we’re facing with program committees. There are only a couple of powerful telescopes in the world and a lot more researchers that want to get time on these telescopes. So previously they had selection committees and call for papers. They ran into exactly the same problems as outlined above, so they came up with a much better way to do this.

The solution: distributed peer review

I’ll try to explain what the Telescope committee did to solve their problems, but I really suggest you take a look at the video first. It explains everything much better than I possibly can.

Their idea is simple, if you submit a paper, you’ll receive a number of papers in return to review, for example six other papers. This is really what peer-reviewing is about, getting reviewed by actual peers. This instantly solves the problem of flooding, if you submit five papers, you’ll receive thirty (!) papers to review, a real penalty.

This way of reviewing is also much more fair, more people will vote and they only have to rate six papers each. So, now I know what you are thinking: this can’t be right, we can game this method! For example, if I see a paper that is a lot like my own paper, but better… I give it a very poor rating. There is a solution for that as well. You can do this of course, but only you will do this, others will still give it a fair higher rating. This information can then be used to give a penalty to your own submitted paper. On the other hand, if your scoring is much like other voters, you’ve done a fair and good job, your paper gets a small bonus. So people are motivated to really take a good look at the few papers they need to rank.

I really like the idea of getting rid of program committees, for some reason it is always feels like there is this group of in-crowd people and they have the tendency to pick friends and colleagues, the same speakers as always. I’m not blaming them, I’m sometimes part of that too! We don’t do it on purpose, it happens automatically! It is the system that is flawed.

So, for the next JavaOne, Devoxx or J-Fall, instead of selecting a committee and giving them the painstaking task of rating all the papers… maybe we should try distributed peer reviews? It just sounds like a much better approach.


The main YouTube video: Telescope Time without Tears - Numberphile
The ‘extra footage’ YouTube video with more details: Telescope Time (extra footage) - Deep Sky Videos
The actual research paper (containing the electoral theory): Telescope time without tears – a distributed approach to peer review

The science behind 'Unknown Pleasures'

The science behind 'Unknown Pleasures'

Joy Division

The album cover of Unknown Pleasures by Joy Division has to be one of the most iconic covers of the 70’s/early 80’s:


The artwork has been re-used and reprinted a lot and is still abundantly present as T-shirt at most music festivals.

But every time I saw this image I wondered… what do those white lines actually represent (if anything)? It turns out the story behind the white lines makes the artwork much cooler!

PSR B1919+21

At Cambridge University in 1967 a 24 year old student named Jocelyn Bell was analysing a huge printout from a radio telescope. This telescope was built by Anthony Hewish and his group of students to look for quasars. Quasars are the dense centers of super massive blackholes, they emit lots of radio waves and visible light. During the analysis Jocelyn noticed something strange, there appeared to be a signal repeating very quickly, at about 1.337 seconds. Surely this had to be some interference from earth, because this isn’t something a quasar could produce.

After some research they could rule out a lot of earth-noise, microwaves, French radio signals, police radio and much more. They found out the signal also didn’t follow ‘earth time’, the normal 24 hours we follow, but rather the sidereal time (star time). In short, when they pointed the telescope to the object again (after earth had rotated) it would be in the same position after 23.9344699 hours. This is a key indicator the signal didn’t come from earth but rather from deep space. Nothing they had previously seen or read about in space could produce such a signal. Jokingly they initially named the signal ‘LGM1’, short for ‘Little Green Men #1’.

The discovery sparked interest from all over the world, and a year later (1968) scientists had come to the conclusion the signal had to come from something called a neutron star. When a star (larger than our sun) collapses it explodes (this is called a supernova), expelling a lot of material into space. This material, stardust, is literally what we are made of! No other process known in space can produce ‘heavy’ elements like iron, nikkel, gold, silver and platinum. Initially people thought this exploding star didn’t have a ‘corpse’ and all matter was blown into space.

In 1934 however, just a year after the neutron was discovered two scientists named Walter Baade and Fritz Zwicky predicted the existance of a neutron star. When large stars collapse they expel stardust but also leave behind a dense neutron star. This star, made of super heavy material, spins around producing radio waves. This is what we now call a pulsar. The signal from Bell and Hewish was the first observed pulsar, now named PSR B1919+21.

Cambridge Encyclopedia

If we look at the Cambridge Encyclopedia of Astronomy there is a page on the discovered pulsar:


The image on the left page is the same as the album cover, it is the signal of our pulsar: PSR B1919+21

Paper sizes

Paper sizes

Update Apr 22, 2016: I’ve made a video which explains most of what is in this blogpost:

Two standards

Yes, this blogpost is about paper. This has absolutely nothing to do with programming, but there is a beautiful piece of math involved.

There are two major standards of paper sizes in the world. The most widely used is ISO-216, more commonly known as the A-series, as in ‘A4’ size. This system is used almost everywhere in the world, the main exceptions are United States and Canada. In the United States they use their own US Letter standard.

US Letter

The standard US Letter has a size of: 216 mm x 279 mm (8.5 by 11 inches) and a ratio of 1,291666666666667.
(I’ll explain why this ratio is important in the math part below!).

The origin of this size is very vague and lost in history. Most origins say (from Wikipedia):

The 11” length of the standard paper being about a quarter of “the average maximum stretch of an experienced vatman’s arms.”

Basically US Letter is a standard because it is a standard, don’t ask questions, just deal with it.

ISO-216, the A-standard

The letter size of the ISO standard is A4. The size is 210 mm × 297 mm and has a ratio of √2 (math!).

The ratio is what makes this standard superior. This of course isn’t a coincidence. Smart people have thought about these sizes, it became a standard because it was superior. The ‘magic’ property A4 paper size has is that is consists of exactly two A5 papers side-by-side. In turn, two of these A4 papers make up the larger A3 paper. This makes it very easy for example to make a booklet in A5 format consisting of folded A4 papers. Also if you scale up a document in A5 it’ll exactly fit A4. If you want to use a copier and print two A5 pages on A4 paper, go ahead! This is impossible to do with US Letter, you’ll end up with white spaces or stretched documents!

Aspect ratio math

How does this work mathematically? The magic hides in the fact that 2 / √2 = √2. Imagine we have a piece of paper with long side A and short side B. If we fold the long side and create a new paper size with B and C, what is the aspect ratio?

A/B = √2 (aspect ratio)
C = A/2 (new short length is A folded in half)

So what is the new aspect ratio of B/C?
B/C = B/(A/2)

B/(A/2) = 2/(A/B)

2/(A/B) = 2/√2

2/√2 = √2!

When you start with the aspect ratio of √2, the resulting folded aspect ratio is again √2. You can keep doing this.

Lets take the largest standard paper size, A0: 841 × 1189. What happens when we fold it? Well: 841 becomes the long side, 1189/2=594.5 the short side. This is indeed the A1 paper size (594 mm x 841 mm). It will keep the magic √2 aspect ratio!

Size of A0 paper

Now that we can explain the aspect ratio, we still don’t know how we ended up with the magic numbers 210 mm × 297 mm. This number originates simply because the A0 paper size is defined as having an aspect ratio of √2 and a surface area of 1 m2.

This is all you need to know, √2 and 1m2.

A*B = 1m2 = 1000² (our paper size)
A/B = √2 (our ratio)

The first formula we need is:

area = (diagonal²) / (ratio + (1/ratio))

When we plug in the given values:
1000² = (diagonal²) / (√2 + (1/√2))

diagonal² = (√2 + (1/√2)) × 1000² ≅ 2121320.34

Remember our magic aspect ratio: 
A / B = √2:
B = A × √2

With our old pal Pythagoras we now know:
diagonal² = A² + B² (= 2121320.34)

Let's get rid of B²:
diagonal² = A² + (A * √2)²

Now we can simplify:
diagonal² = A² + (A × √2)²
diagonal² = A² + 2 × A²
diagonal² = 3 × A²

And easily calculate the result:
3 × A² = 2121320.34

A = √(2121320.34 / 3) ≅ 840.89
B = A × √2 ≅ 1189.20

We started with just two simple numbers, ratio: √2 and area: 1m2 and now we’ve ended up with the A0 paper, 841 mm and 1189 mm!
To calculate the rest of the A-series you just take:

A' = B / 2
B' = A

Mathematically folding it in half results in: 594 mm x 841 mm = exactly the A1 paper size!


Keep on folding

When we take an A4 paper and keep folding it, we get the following aspects (aspects fluctuate a little bit due to rounding):

A4	210 mm × 297 mm ratio: 1.414
A5	148 mm × 210 mm ratio: 1.419
A6	105 mm × 148 mm ratio: 1.409
A7	74  mm × 105 mm ratio: 1.418
A8	52  mm × 74  mm ratio: 1.423
A9	37  mm × 52  mm ratio: 1.405
A10	26  mm × 37  mm ratio: 1.423

But what do you end up with folding the US Letter? Let’s see:

216 mm x 279 mm ratio: 1.291
139 mm x 216 mm ratio: 1.554 <- What?
108 mm x 139 mm ratio: 1.287 <- Ah..
69  mm x 108 mm ratio: 1.565 <- HUH!?
54  mm x 69  mm ratio: 1.278
34  mm x 54  mm ratio: 1.588
27  mm x 34  mm ratio: 1.259 <- Oh god...

This fluctuating ratio results in so much wasted space, ink, paper! And it is just ugly! If you decide to scale something up from A5 to A4 it instantly fits, if you scale something in US Letter… you’ll either have to crop or stretch or leave unprinted paper.

US Letter is bad for the environment!

Ban the US Letter standard, hurray for math!