Java reasoning

20 August 2018

Chris Sawyer comments on OpenJDK and Oracle JDK, the importance of test-driven development and UI colour palettes.

Java 10 kicked off the regular six-monthly release schedule for new releases of the OpenJDK and before the end of September, roughly on schedule, Java 11 will be upon us. Oracle JDK is still the version that will be used by the finance industry, which naturally favours stability – it takes a snapshot of the OpenJDK and then maintains it for three years.

Apart from a few minor tweaks and the inclusion of a few closed-source utilities/APIs, both versions are identical; same codebase, same developers, same build process. Almost all Java commercial applications still require an Oracle JDK though, and will pop-up warnings if they find the OpenJDK one.

One of the most intriguing features coming up in JDK 11 is the ‘Launch Single File Source Code Programs’ feature. For a single Java file, this means that you can skip the compilation step and just type ‘java file.java’ and it will be compiled and run in a single step. This is the first step in an interesting chain:

• Skip compilation for single file executables.
• Remove the ‘boilerplate’ for ‘public static void main’ signature thus making Java far more accessible to non-Java devs/administrators.
• Add shebang support.

The last point is of most interest. The Shebang sequence is the ‘#!’ that is seen as the first line of a text/script file on the Linux platform. If the program loader sees this character combination, it runs an interpreter over the file and executes it as if it’s a ‘normal’ executable program.

There are numerous executable script files required just to log you in to Linux and extending this to Java allows for the intriguing possibility of writing scripting files in Java instead of Bash. If this becomes reality, it won’t be long before there are utilities that convert from a standard Java application structure — one public class per file, etc. into a single enormous script file.

Would Java script files become popular on Linux? Maybe.

Punch cards and testing

Running with punch cards once, I banged my arm on a door frame and spilt them everywhere. It took forever to re-sort them into the correct sequence – I could not tell if it was my code or the card order. Fortunately, this failing wasn’t expensive or serious but I was lucky.

In 1962, NASA launched the Mariner 1 spacecraft and four minutes later it had to be destroyed. In the days of punch cards, the programmer wasn’t always the person who entered the program into the computer. This left a degree of interpretation as to what was specified, as well as typos. The desired, hand-written formula was ‘R dot bar (subscript) n’. R was the radius, ‘.’ was the first derivative, or velocity, ‘n’ was the increment and that leaves the ‘bar’. Think of a fat, wider hyphen, but not a hyphen. The bar meant smooth out/average the trajectory and it was this that was entered into the computer as a hyphen.

But the trajectory should not have been smoothed out to begin with and consequently veered off course after a few minutes. In today’s money, around $135m went up in smoke. The same code had been used several times before but an unfortunate series of hardware failures meant this code was executed.

The importance of test-driven development cannot be underestimated and the more we adhere to such practices in the face of customers who want executable code progress over tested code, the more we’ll be respected in the end. It’s far, far better to deliver fewer lines of tested code than a whole heap of untested routines. Untested code is just conceptual ideas. Clients want the cake, not the cake mixture and it’s in the testing/baking that we prove ourselves. Had these concepts been established in 1962, could this bug have been caught? Maybe.

So often, the roots of User Experience theory hark back to human evolution. From users subconsciously favouring white space around a UI – the savannah principle; on a savannah you can see all around you and cannot be snuck-up on – to the use of colours, coming potentially from brightly coloured poisonous berries or animals, and the use of some societies’ brightly coloured signs as warnings or instructions (bright red for ‘stop’, green for ‘go’). But it’s not always a good choice to use red and green for buttons. Protanopia and Deuteranopia (red-green) are the most common form of colour-blindness and thus red and green UI objects might not have the same impact for everyone.

There are several fantastic resources on the web to help with selecting colours that maximise discern-ability as well as being pleasing combinations. Regardless of the developing languages used, if you need to select more than one colour, then use/search for these tools:

I want hue: a great name and a fantastic tool for generating colour palettes.
ChromaJS: a brilliant library for manipulating and unifying colours.
ColorBrewer: a great tool for checking how colours combine.

Even if you have no interest in UI coding, they’re fascinating sites to investigate.