Java Deep

Pure Java, what else

Java 9 by Example, My New Book

Sometime during the summer, I decided to write a book on Java programming after being suggested to do so by Packt. Java is a market leader and the number one programming language in the enterprise programming arena, and learning it is a good option for novice programmers. I recommend it to be learned as a main language after you got your fingers burnt with languages that have a simpler ecosystem, such as Python, Delphy, VisualBasic, and so on. Many advocate the death of Java but I do not share their opinion. There may be more modern and fancier languages, but for enterprise computing Java is still there and will be there, at least for the next 20 years. If you learn Java now, you learn an actively developing, stable, and reliable environment and tool, and you gain significant knowledge that you can convert to “jobs” in the coming decades.

An overview of the book

While designing the book, I decided to address those readers who already have some programming experience and want to learn Java as a main language, but apart from that, the book starts with the basics. Java 9 is especially good to get started since it has a REPL interpreter that compiles the Java code you type in, so you can try the features interactively. Throughout the book, you will see sample programs, first simple ones and then more complex examples, that are explained in detail. We focus not only on the language features, such as module support, functional programming, lambda expressions, and reactive interfaces, but also on programming style and program design. Continuously tutoring and coaching junior developers in my everyday work, I have gathered some experience on what is important and yet easily overlooked by beginners, and I have focused on these issues in the book.

The examples include sorting algorithms, explaining bubble and quick short, a game called Mastermind, a sample e-Commerce application, and a simple accounting application. The game, Mastermind, is followed in three chapters: the basic algorithm, a massively parallel algorithm (which is not trivial for this problem), and a web application where you can finally see the colors on the screen.

Finishing the book, the reader will have a comprehensive view of the language and will gain a stable basic knowledge to study further in the special directions he or she chooses.

Java 9 by Example Book Cover

How to get the book

This book is currently work in progress at the moment. You can however get an early access eBook from the Packt Website at Here you can see pre-reviewed drafts of the chapters as they are written, giving you access to content as early as possible. To know more about Early Access click on the below link.

Final volatile

I was writing my book over the weekend and I was looking for some simple example that could demonstrate the real need of volatile modifier in multi-thread code. Years ago when I last time demonstrated the multi-thread capability Java was still 32-bit, or at least there was 32-bit Java available. On 32 bits you could concurrently increment long variables and because the lower and upper 32 bits were handled in different processor shift there was a chance that two threads garbled some way the non-volatile variable. Now with Java 9 this is not the case. Now Java is 64-bit and I had to demonstrate the need for a volatile on 64-bit before anyone comes up the stupid idea that it was only needed for 32-bit. (I could tell stories, but I try to keep it a professional blog. Not with much success, but still.)

I was searching stackoverflow and found this page that contains many meaningless, or less than usable answer (which clearly demonstrates that the topic is not simple) but it also contains a sample from Jed Wesley-Smith that inspired my demonstrating code for the book:


public class VolatileDemonstration implements Runnable {
    private Object o = null;
    private static final Object NON_NULL = new Object();
    public void run() {
        while( o == null );
        System.out.println("o is not null");
    public static void main(String[] args)
                           throws InterruptedException {
        VolatileDemonstration me = new VolatileDemonstration();
        new Thread(me).start();
        me.o = NON_NULL;

This code will never finish, unless you convert the field o volatile. We also need the 1000ms sleep to allow the JIT to optimize the code of the method run() after which it never reads the variable o ever again. The JIT assumes intra-thread semantics and takes the liberty to optimize the code that way. (Java Language Specification 17.4.7)

But what happens if you have a field that you can not convert to volatile? What? Can’t you just write the keyword volatile in front of the type Object? Perhaps I was giving too much hint in the title of the article…

A final field can not be volatile. Of course: a final can not change, there is no point to re-read it from the main memory and waste CPU cycles for the synchronization of any change of it between the CPU caches. But that is not true.

Final variables can be changed once.

This is something that novice Java developers tend to forget. When an object is created any final field has the zero value. In case of an object this value is null. The field has to get its final value until the end of the initialization process, that is until the end of the execution of the constructor (any constructor). Look at the following code:


public class VolatileDemonstration implements Runnable {
    private final Object o;
    private static final Object NON_NULL = new Object();
    public void run() {
        while( o == null );
        System.out.println("o is not null");

    public VolatileDemonstration() throws InterruptedException {
        new Thread(this).start();
        this.o = NON_NULL;

The constructor starts the new thread, sleeps and then sets the field that can not be volatile. What is the solution?

What solution? There is no solution! This is a demonstration code. Just don’t write code that does things like this: that is the solution. OK?


What can we learn from this? Not all of the followings can be directly implied from the above, but they are all related to the phenomenon. I could write a longer article leading to any of the followings but it would have only abused your patience.


  • Final fields can be changed once. It is not true that they are not changing never (sic).
  • A thread may read the value of a final field once and it may not read it ever again. If the JVM runs for years the thread may keep the value in the thread context in some registry or CPU cache for years as long as it likes.
  • Never let this escape from the constructor.
  • Among other more trivial things the “never let this escape from the constructor” also means not to pass it as argument to a method that can be overridden or not under the control of the programmer, who is responsible for the current class.
  • Write well behaving code or else you will suffer the slings and arrows of your outrageous program.


  • See the takeaways for juniors and teach them.
  • You have a nice brain twister code for education.
  • Java is not a perfect language allowing such constructs. But do not tell juniors. When they realize it they are already seniors and then it is just too late.
  • The solution is a liquid mixture in which the minor component is uniformly distributed within the major component.

Microbenchmarking comes to Java 9

I have not written article here for a few months and this will also continue with this exception. I plan to return writing around next year March. Explanation at the end of the this article. Wait! Not exactly at the end, because you could just scroll down. It is somewhere towards the end of the article. Just read on!

Three years ago I was writing about how Java compiler optimizes the code it executes. Or rather how javac does not do that and the same time JIT does. I made some benchmarks, some really bad ones as it was mentioned by Esko Luontola. These benchmarks were meant to show that JIT optimize even before it could gather significant statistical data about the execution of the code.

The article was created in January 2013. and the very first source code upload of JMH (Java Microbenchmark Harness) happened two month later. Since that time the harness developed a lot and next year it becomes part of the next release of Java. I have a contract to write a book about Java 9, and its chapter 5 should cover Java 9 microbenchmarking possibilities, among other things. It is a good reason to start something to play with around JMH.

Before getting into the details how to use JMH and what it is good for, let’s talk about a bit microbenchmarking.


Microbenchmarking is measuring the performance of some small code fragment. It is rarely used and before starting to do a microbenchmark for real commercial environment we have to think twice. Remember that premature optimization is root of all evil. Some developers created a generalization of this statement saying that optimization itself is root of all evil, which may be true. Especially if we mean microbenchmarking.

Microbenchmarking is a luring tool to optimize something small without knowing if it is worth optimizing that code. When we have a huge application that has several modules, run on several servers how can we be sure that improving some special part of the application drastically improves the performance? Will it pay back in increased revenue that generates so much profit that will cover the cost we burnt into the performance testing and development? I am reluctant to say that you can not know that but only because such a statement would be too broad. Stadistically almost sure that such an optimization including microbenchmarking will not pain off most of the time. It will hurt, you just may not notice it, or even enjoy it, but that is a totally different story.

When to use microbenchmarking? I can see three areas:

  1. You write an article about microbenchmarking.
  2. You identified the code segment that eats most of the resources in your application and the improvement can be tested by microbenchmarks.
  3. You can not identify the code segment that will eat most of the resources in an application but you suspect it.

The first area is a joke. Or not: you can play around with microbenchmarking to understand how it works and then to understand how Java code works, what runs fast and what does not. Last year Takipi posted an article where they tried to measure the speed of lambdas. Read it, very good article and clearly demonstrates the major advantage of blogging over writing something for the print. Readers commented and pointed out errors and they were corrected in the article.

The second is the usual case. Okay, before a reader, commented corrects me: the second should have been the usual case. The third is when you develop a library and you just do not know all the applications that will use it. In that case you will try to optimize the part that you think is the most crucial for most of the imagined, suspected applications. Even in that case it is better to take some sample applications.


What are the pitfalls of Microbenchmarking? Benchmarking is done as experiment. The first programs I wrote were TI calculator code and I could just count the number of steps the program made to factor two large (10 digits that time) prime numbers. Even that time I was using an old Russian stop watch to measure the time being lazy to calculate the number of steps. Experiment and measurement was easier.

Today you could not calculate the number of steps the CPU makes. There are so many small factors that may change the performance of the application that are out of control of the programmer that it is impossible to make a calculation of the steps. We have the measurement left for us and we gain all the problems with all the measurements.

What is the biggest problem of measurements? We are interested in something, say X and we usually can not measure that. So we measure instead Y and hope that the value of Y and X are coupled together. We want to measure the length of the room, but instead we measure the time it takes for the laser beam to travel from one end to the other. In this case the length X and the time Y are strongly coupled. Many times X and Y only correlate more or less. Most of the times when people do measurement the values X and Y have no relation to each other at all. Still people put their money and more on decisions backed by such measurements. Think about the political elections as an example.

Microbenchmarking is no different. It is hardly ever done well. If you are interested in details and possible pitfalls Aleksey Shipilev has a good one hour video. The first question is how to measure the execution time. Small code runs short times and System.currentTimeMillis() may just return the same value when the measurement starts and when it ends, because we are still in the same millisecond. Even if the execution is 10ms the error of the measurement is still at least 10% purely because of the quantization of the time as we measure. Luckily there is System.nanoTime(). We happy, Vincent?

Not really. nanoTime() returns the current value of the running Java Virtual Machine’s high-resolution time source, in nanoseconds as the documentation says. What is “current”? When the invocation was made? Or when it was returned? Or sometime between? Select the one you want and you may still fail. That current value could have been the same during the last 1000ns that is all Java implementations should guarantee.

And another caveat before using nanoTime() from the documentation: Differences in successive calls that span greater than approximately 292 years (263 nanoseconds) will not correctly compute elapsed time due to numerical overflow.

292 years? Really?

There are other problems as well. When you start up a Java code the first few thousand executions of the code will be interpreted or executed without run-time optimization. JIT has the advantage over compilers of statically compiled languages like Swift, C, C++ or Golang that it can gather run-time information from the execution of the code and when it sees that the compilation it performed last time could have been better based on recent run-time statistics it compiles the code again. The same may be true for the garbage collection that also tries to use statistics to tune its operational parameters. Because of this well written server applications gain a bit of performance over time. They start up a bit slower and then they just become faster. If you restart the server the whole iteration starts again.

If you do micro benchmarks you should care about this behavior. Do you want to measure the performance of the application during warm-up time or how it really executes during operation?

The solution is a micro benchmarking harness that tries to consider all these caveats. The one that gets to Java 9 is JMH.

What is JMH?

“JMH is a Java harness for building, running, and analyzing nano/micro/milli/macro benchmarks written in Java and other languages targeting the JVM.” (quote from the official site of JMH)

You can run jmh as a separate project independent from the actual project you measure or you can just store the measurement code in a separate directory. The harness will compile against the production class files and will execute the benchmark. The easiest way, as I see, is to use the Gradle plugin to execute JMH. You store the benchmark code in a directory called jmh (the same level as main and test) and create a main that can start the benchmark.

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.runner.Runner;
import org.openjdk.jmh.runner.RunnerException;
import org.openjdk.jmh.runner.options.Options;
import org.openjdk.jmh.runner.options.OptionsBuilder;

public class MicroBenchmark {

public static void main(String... args) throws IOException, RunnerException {
Options opt = new OptionsBuilder()

new Runner(opt).run();

There is a nice builder interface for the configuration and a Runner class that can execute the benchmarks.

Playing a bit

In the book Java 9 Programming By Example one of the examples is the Mastermind game. Chapter 5 is all about solving the game parallel to speed up the guessing. (If you do not know the game, please read it on Wikipedia, I do not want to explain it here, but you will need it to understand the following.)

The normal guessing is simple. There is a secret hidden. The secret is four pegs of four different color out of 6 colors. When we guess we take the possible color variations one after the other and ask the question the table: if this selection is the secret are all answers correct? In other words: can this guess be hidden or is there some contradiction in the answers for some previous answers? If this guess can be the secret then we will give it a try putting the pegs on the table. The answer may be 4/0 (alleluia) or something else. In the latter case we go on searching. This way the 6 color, 4 columns table can be solved in five steps.

For the sake of simplicity and visualization we name the colors with numbers, like 01234456789 (we have ten colors in the jmh benchmark since 6 colors are just no enough) and 6 pegs. The secret we use is 987654 because this is the last guess as we go from 123456, 123457 and so on.

When I first coded this game in August 1983 on a Swedish school computer (ABC80) in BASIC language each guessing took 20 to 30 seconds on the z80 processor running on 40MHz 6 colors, 4 positions. Today my MacBook Pro can play the whole game using single thread approximately 7 times in a second using 10 colors and 6 pegs. But that is not enough when I have 4 processors in the machine supporting 8 parallel threads.

To speed up the execution I split up the guess space into equal intervals and I started separate guessers each spitting guesses into a blocking queue. The main thread reads from the queue and puts the guesses on the table as they come. There are some post processing that may be needed in case some of the threads create a guess that becomes outdated by the time the main thread tries to use it as a guess but still we expect huge speed up.

Does it really speed up the guessing? That is JMH here for.

To run the benchmark we need some code that actually executes the game

public static class ThreadsAndQueueSizes {
@Param(value = {"1", "4", "8", "16", "32"})
String nrThreads;
@Param(value = { "1", "10", "100", "1000000"})
String queueSize;


public void playParallel(ThreadsAndQueueSizes t3qs) throws InterruptedException {
int nrThreads = Integer.valueOf(t3qs.nrThreads);
int queueSize = Integer.valueOf(t3qs.queueSize);
new ParallelGamePlayer(nrThreads, queueSize).play();

public void playSimple(){
new SimpleGamePlayer().play();

The JMH framework will execute the code several time measuring the time to run with several parameters. The method playParallel will be executed to run the algorithm for 1, 4, 5, 10 and 32 threads each with 1, 10, 100 and one million maximum queue length. When the queue is full the individual guessers stop with their guessing until the main thread pulls at least one guess off the queue.

I suspected if we have many threads and we do not limit the length of the queue then the worker threads will fill the queue with initial guesses that are just based on an empty table and thus does not deliver much value. What do we see after almost 15 minutes of execution?

Benchmark                    (nrThreads)  (queueSize)   Mode  Cnt   Score   Error  Units
MicroBenchmark.playParallel            1            1  thrpt   20   6.871 ± 0.720  ops/s
MicroBenchmark.playParallel            1           10  thrpt   20   7.481 ± 0.463  ops/s
MicroBenchmark.playParallel            1          100  thrpt   20   7.491 ± 0.577  ops/s
MicroBenchmark.playParallel            1      1000000  thrpt   20   7.667 ± 0.110  ops/s
MicroBenchmark.playParallel            4            1  thrpt   20  13.786 ± 0.260  ops/s
MicroBenchmark.playParallel            4           10  thrpt   20  13.407 ± 0.517  ops/s
MicroBenchmark.playParallel            4          100  thrpt   20  13.251 ± 0.296  ops/s
MicroBenchmark.playParallel            4      1000000  thrpt   20  11.829 ± 0.232  ops/s
MicroBenchmark.playParallel            8            1  thrpt   20  14.030 ± 0.252  ops/s
MicroBenchmark.playParallel            8           10  thrpt   20  13.565 ± 0.345  ops/s
MicroBenchmark.playParallel            8          100  thrpt   20  12.944 ± 0.265  ops/s
MicroBenchmark.playParallel            8      1000000  thrpt   20  10.870 ± 0.388  ops/s
MicroBenchmark.playParallel           16            1  thrpt   20  16.698 ± 0.364  ops/s
MicroBenchmark.playParallel           16           10  thrpt   20  16.726 ± 0.288  ops/s
MicroBenchmark.playParallel           16          100  thrpt   20  16.662 ± 0.202  ops/s
MicroBenchmark.playParallel           16      1000000  thrpt   20  10.139 ± 0.783  ops/s
MicroBenchmark.playParallel           32            1  thrpt   20  16.109 ± 0.472  ops/s
MicroBenchmark.playParallel           32           10  thrpt   20  16.598 ± 0.415  ops/s
MicroBenchmark.playParallel           32          100  thrpt   20  15.883 ± 0.454  ops/s
MicroBenchmark.playParallel           32      1000000  thrpt   20   6.103 ± 0.867  ops/s
MicroBenchmark.playSimple            N/A          N/A  thrpt   20   6.354 ± 0.200  ops/s

(In score the more is the better.) It shows that the best performance we get if we start 16 threads and if we somewhat limit the length of the queue. Running the parallel algorithm on one thread (a mater and a worker) is somewhat slower than the single thread implementation. This seems to be okay: we have the overhead of starting a new thread and communication between the threads. The maximum performance we have is around 16 threads. Since we can have 8 cores in this machine we expected the peek around 8. Why is that?

What happens if we replace the standard secret 987654 (which is boring after a while even for a CPU) with something random?

Benchmark                    (nrThreads)  (queueSize)   Mode  Cnt   Score   Error  Units
MicroBenchmark.playParallel            1            1  thrpt   20  12.141 ± 1.385  ops/s
MicroBenchmark.playParallel            1           10  thrpt   20  12.522 ± 1.496  ops/s
MicroBenchmark.playParallel            1          100  thrpt   20  12.516 ± 1.712  ops/s
MicroBenchmark.playParallel            1      1000000  thrpt   20  11.930 ± 1.188  ops/s
MicroBenchmark.playParallel            4            1  thrpt   20  19.412 ± 0.877  ops/s
MicroBenchmark.playParallel            4           10  thrpt   20  17.989 ± 1.248  ops/s
MicroBenchmark.playParallel            4          100  thrpt   20  16.826 ± 1.703  ops/s
MicroBenchmark.playParallel            4      1000000  thrpt   20  15.814 ± 0.697  ops/s
MicroBenchmark.playParallel            8            1  thrpt   20  19.733 ± 0.687  ops/s
MicroBenchmark.playParallel            8           10  thrpt   20  19.356 ± 1.004  ops/s
MicroBenchmark.playParallel            8          100  thrpt   20  19.571 ± 0.542  ops/s
MicroBenchmark.playParallel            8      1000000  thrpt   20  12.640 ± 0.694  ops/s
MicroBenchmark.playParallel           16            1  thrpt   20  16.527 ± 0.372  ops/s
MicroBenchmark.playParallel           16           10  thrpt   20  19.021 ± 0.475  ops/s
MicroBenchmark.playParallel           16          100  thrpt   20  18.465 ± 0.504  ops/s
MicroBenchmark.playParallel           16      1000000  thrpt   20  10.220 ± 1.043  ops/s
MicroBenchmark.playParallel           32            1  thrpt   20  17.816 ± 0.468  ops/s
MicroBenchmark.playParallel           32           10  thrpt   20  17.555 ± 0.465  ops/s
MicroBenchmark.playParallel           32          100  thrpt   20  17.236 ± 0.605  ops/s
MicroBenchmark.playParallel           32      1000000  thrpt   20   6.861 ± 1.017  ops/s

The performance increases since we do not need to go though all the possible variations. In case of one thread the increase is double. In case of multiple threads the gain is not that much. And note that this does not speed the code itself up, only measures more realistically using statistical, random secrets. What we can also see that the gain of 16 threads over 8 threads is not significant any more. This is significant only when we select a secret that is towards the end of the variations. Why? From what you have seen here and from the source code available in GitHub you can give an answer to that.


The book Java 9 Programming By Example is planned to be released February 2017. But since we are living in an open source world you can get access controlled by the publisher to 1.x.x-SNAPSHOT versions. Now I told you the preliminary GitHub URL that I use while I develop code for the book and you can also preorder the eBook and give feedback helping me to create a better book.

Try and Catch in Golang

Golang as opposed to Java does not have exceptions, try/catch/finally blocks. It has strict error handling, functions called panic and recover and a statement named defer. It is a totally different approach. Is it better or is the Java approach the superior? (Sorry that I keep comparing it to Java. I am coming from Java world.)

When we handle exceptional cases in Java we enclose the commands into a ‘try’ block denoting that something may happen that we want to handle later in a ‘catch’ block. Then we have the ‘finally’ block that contains all the things that are to be executed no matter what. The problem with this approach is that it separates the commands that belong to the same concern. We want to deal with some file. So we open a file and later, no matter what, we want to close it. When the programmer writes the finally block the file opening is far away somewhere at the start of the method. To remember all the things that we have to do to clean up the actions at the start of the method you have to scroll up to the start of the method where the ‘try’ block starts.

Okay! I know that your method is too long if you have to scroll back. Your methods follow clean code principles and are not longer than ten lines each including JavaDoc. Even though the issue is still there. It is formulated according to order the execution is expected and not according to the order the logic dictates. The logic says the following: if I open a file, I will want to close it. If I allocate some resource I will want to release it. It is better keeping the concerns together. We are not programing in assembly where you write the mnemonics in the strict order of execution. We define the algorithmic solution in a high level language and the compiler will generate the assembly. Real work has to be done by the brain, mechanical work is for the CPU. These days we have CPUs.

Golang has the command ‘defer’ for the purpose. You open a file and you mention on the next line that you will want it to be closed some time calling the function you provide. This is the much better approach, which the developers of the Java language also know hence introducing the interface ‘closeable’ and try-with-resources statement.

Still programmers coming from the Java world begin introduced to Go are longing for exception handling. If you really want you can mimic it in Go. It will not be the same and I do not really get the point why to ruin something that is good to something old and mediocre, but you can write

		Try: func() {
			fmt.Println("I tried")
		Catch: func(e Exception) {
			fmt.Printf("Caught %v\n", e)
		Finally: func() {

Homework: find out the sample code that is before these lines (Go constructs) that make this possible. Solution is here:

package main

import (

type Block struct {
	Try     func()
	Catch   func(Exception)
	Finally func()

type Exception interface{}

func Throw(up Exception) {

func (tcf Block) Do() {
	if tcf.Finally != nil {

		defer tcf.Finally()
	if tcf.Catch != nil {
		defer func() {
			if r := recover(); r != nil {

func main() {
	fmt.Println("We started")
		Try: func() {
			fmt.Println("I tried")
		Catch: func(e Exception) {
			fmt.Printf("Caught %v\n", e)
		Finally: func() {
	fmt.Println("We went on")

See also a recent similar solution at from Tim Henderson

Do not (only) meet the budget

In a previous article I wrote

The actual decision (of a software architect) should lead to a solution that meets availability, performance, reliability, scalability, manageability and cost criteria. (Btw: the first six criteria should be met, the last one should be at least met and minimized, but that is a different story.)

Many times the criteria are met and there is no intention to minimize the cost. “There is a budget and we have to fit into it.” This is the approach teams follow. There are several reasons for it. But the reasons do not necessarily mean that the approach is ok. I may even accept the argument that this behaviour is unavoidable in large organizations.

Why is this approach bad?

When you sell something you want to sell it the highest price you can. Cost represents a minimum for the selling price: if the reachable price is lower than the cost to reproduce then production will stop. Budget is also a limiting factor. You go to the food shop and you buy the bread that meets your likes and is the cheapest among those if you have the money. If your money is limited you will select one that you can pay for. Why would one buy the more expensive if all other criteria they need are met?

(Do not start to talk about Apple products: feeling you are rich is also a need.)

The same is true for development projects even if the customer buying the development is in the same company. Your customer is either “business” if you are an in-house team or sales in case your company develops software for customes. In the latter case the “customer customers” are the customer of the company. The customer of the development team is sales. Same company. Customer provides the budget that you have to fit in but

nobody ever complained that a project was under budget.

I am not talking about lower budget commitment. All projects have risks and all risks have financial impact. One way of risk mitigation is to have contingency in the budget. But again: that is the budget and not the actual spending. Still teams, departments tend to fill their budget. Why do they do that? There can be several reasons and sure I will not be able list all possible.

Reasons to spend more


The more a department spends the more important it looks. I have seen such company. The company was a large expanding company heavily investing into assets, building infrastructure for years (like telecom infrastructure, roads or railways, I won’t tell you which one) and the one who was building the more miles the better performer was. The measurement was the spent money and this culture remained when it was IT spending. Weird.


In some companies budget not spent will lessen the financing possibilities of the department for the future. If you, as a software architect can save up from the original estimates it means your estimation was not good. That will be taken into account next time you estimate. Thus the department rather wastes (usually towards end of the year) the budget left over than giving it back to treasury. It is like fixing a bug creating another. (How about unit testing departments?)


Some companies underfinance maintenance, developer trainings, education, equipment or some other IT related activities and departments tend to amend the situation from other sources: overbudgeting projects. Things certainly will happen. If you want to have something you do not pay for you will not get it. If you got it you paid for it just you do not know where, when and how much. Developers, architect, project managers may even not realize that they follow this practice in some cases. I have heard a few times the argument: “We select the more expensive technology X for the project because this way we can learn it.” This is also crossfinancing. You use the project to finance the developer’s education.

All these are bad practices. I do not need to explain the first example. The second is also quite obvious. The last one, cross financing is not that obvious.

Why cross financing is bad

When you select the more expensive technology (it may be more expensive because it has license fees, or needs more development, learning) you decide to invest the company money into something. As an architect it is not your responsibility. You may suggest that to management but you should not decide even if you are in the position that you can (unless you are also the management in a small company, but in that case you decide with your management hat on). It is only management who can decide how to invest the money. Investing into people is always a good investment even if they leave your company later. (But what if you do not invest and they stay?) But as a matter of fact management may see even more lucrative investment possibilities at that very moment.

Don’t feel bad

Do I suggest that you rush to management now and ask them to lessen your budget? Do I think that you, as a software architect should feel bad if you fill the budget and cross finance?

Not at all. I said that crossfinancing is bad practice but I did not say that it is YOUR bad practice. It is a bad practice implemented in a company. The larger the organization is the more difficult it is to change it. And it is not your task, and more importantly you may not have the capabilities to do that.

The only thing you have to: know that you follow a practice that is not optimal, so to say. If there is any chance to improve it just a little bit, go for it. Everybody making one small step will save the world.

Architects Don’t Decide

As pointed out in the article A Little Architecture from Robert C. Martin the job of the architect is not

…to lead a team and make all the important decisions about databases and frameworks and web-servers and all that stuff.

It is to make

decisions that a Software Architect makes are the ones that allow you to NOT make the decisions about the database, and the webserver, and the frameworks.

As the article pointed out juniors have many times different view about the tasks that a senior does than the senior who does it. It is not only the subject of the decision however. This is a bit more. Juniors see the position of an architect as a position of power. He has the right and the power to make decisions. Having the power is always good. You long to have the position of power, don’t you. Up to certain age, maturity.

When you get into the position of being an architect you realize that the power is not a privilege. It is a reponsibility. The system the team develops, the architecture, the network, hardware, the operation is not a play field to satisfy your curiosity. It is a professional environment that works based on profit and lost, budget and costs, money, money, money. The decision the architect makes should not be biased by the actual person’s interest. This is, by the way, a very common mistake. “Let’s use NoSQL because that is so fancy! We have to use big data!”

The actual decision should lead to a solution that meets availability, performance, reliability, scalability, manageability and cost criteria. (Btw: the first six critera should be met, the last one should be at least met and minimized, but that is a different story.)

The actual decisions on the architecture and solutions (finally when unavoidable also about framework and database and other stuff) depends on many things. License structure, license cost, company culture, available developers, deadline/time to market, architecture already in place to name a few. If you consider all the constraints you have to meet you will not have too many choices. There will be compromises and finally you will end up with the only one selection that fits. That one is going to be your decision.

Did you really make a decision?

Code Naked

  • I can not merge your pull request on our Git.
  • Why?
  • There is only one file modified.
  • That is because we modified only one Java class.
  • That is exactly the problem. I can not see in the pull request the modified JUnit test.
  • I could not modify the unit test because there was no any.
  • I see. And that is a problem of the past. The present problem is that still there is no unit test.
  • But we have no time to write unit test for the whole program. There are zillion of lines of code developed during the last few hundred years. They have no unit tests and they just work.
  • I acknowledge that. That is the life when you maintain legacy code. But why did not you write unit test for the change you just created?
  • There are zillion of lines already…
  • Yes, those that “work”. But your change is new. How do you know that it works?
  • We just agreed that we do not start to write unit tests now. We do ad-hoc testing.
  • Okay. Then let’s just get back to the basics. Why do we have unit tests? What is the primary reason?
  • To have working and tested code.
  • Im my opinion this is more like documenation. Unit test is a live documentation that is more likely to be maintained than any other documenation. You just created a few lines of code without documentation.
  • I get your point, but we just do not have time for that.
  • Let’s look at the following situation. It is summer and hot. You wake up late and want to rush to fetch the bus. You take the shower and drink your coffe and run to the bus. Right?
  • Right.
  • You do not even dress. Run out naked.
  • No! No! I dress!
  • But you have no time. You are in a rush. If you have time to dress yourself why do you let your code run to production without unit tests naked?
  • I get the point. But you can survive without unit tests. If you run on the street naked you will not survive.
  • Why is that? The summer is hot, you will not catch cold.
  • Yeah, but police would catch you.
  • So this is a kind of society issue, is it?
  • Yes, it is.
  • And the coding society is not that matured yet, it lets you run naked without unit tests.
  • I assume… yes.

we still have a long way to go ahead of us…

Comparing Golang with Java

First of all I would like to make a disclaimer. I am not an expert in Go. I started to study it a few weeks ago, thus the statements here are kind of first impressions. I may be wrong in some of the subjective areas of this article. Perhaps I will write some time a review of this one later. But until then, here it is and if you are a Java programmer, you are welcome to see my feelings and experiences and the same time you are more than welcome to comment and correct me if I am wrong in some statements.

Golang is impressive

As opposed to Java, Go is compiled to machine code and is executed directly. Much like C. Because this is not a VM machine it is very much different from Java. It is object oriented and the same time functional to some extent thus it is not only a new C with some automated garbage collection. It is somewhere between C and C++ if we think the world of programming languages is on a single line, which it is not. Using a Java programmer’s eyes some things are so much different that learning them is challenging and may give a deeper understanding on programming language structures and how objects, classes and all these things are … even in Java.

I mean that if you understand how OO is implemented in Go, you may understand also some of the reasons why Java has them different.

In short if you are impatient: do not let yourself freak out by the seemingly weird structure of the language. Learn it and it will add to your knowledge and understanding even if you do not have a project to be developed in Go.

GC and not GC

Memory management is a crucial point in programming languages. Assembly lets you do all things. ​Or rather it requires you to do it all. In case of C there are some support functions in the standard library but it is still up to you to free all memory that you have allocated before calling malloc. Automated memory management starts somewhere along C++, Python, Swift and Java. Golang is also in this category.

Python and Swift use reference counting. When there is a reference to an object the object itself holds a counter that counts the number of references that point to it. There are no pointers or references backward, but when a new reference gets the value and starts to reference an object the counter increases and when a reference becomes null/nil whatever or references another object the counter goes down. So it is known when the counter is zero, there are no references to the object and it can be discarded. The problem with this approach is that an object still may be unreachable while the counter is positive. There can be object circles referencing each other and when the last object in this circle is released from the static, local and otherwise reachable references then the circle starts to float in the memory like bubbles in water: the counters are all positive but the objects are unreachable. The Swift tutorial has a very good explanation of this behavior and how to avoid it. But the point is still there: you have to care about memory management somewhat.

In case of Java, other JVM languages (including the JVM implementation of Python) the memory is managed by the JVM. There is a full blown garbage collection that runs from time to time in one or more threads, parallel with the working threads or sometimes stopping those (a.k.a. stop the world) marking the unreachable objects, sweeping them and compacting the presumably scattered memory. All you have to worry about is performance if at all.

Golang is also in this category with a small little, tiny exception. It does not have references. It has pointers. The difference is crucial. It can be integrated with external C code and for performance reasons there is nothing like a reference registry in the run-time. The actual pointers are not known to the execution system. The memory allocated can still be analyzed to gather reachability information and the unused “objects” can still be marked and swept off, but memory can not be moved around to do the compacting. This was not obvious for me some time from the documentation and as I understood the pointer handling I was seeking for the magic that Golang wizards implemented to do the compacting. I was sorry to learn, they simply did not. There is no magic.

Golang has a garbage collection but this is not a full GC as in Java, there is no memory compaction. It is not necessarily bad. It can go a long way running servers very long time and still not having the memory fragmented. Some of the JVM garbage collectors also skip the compacting steps to decrease GC pause when cleaning old generations and do the compacting only as a last resort. This last resort step in Go is missing and it may cause some problem is rare cases. You are not likely to face the problem while learning the language.

Local variables

Local variables (and sometimes objects in newer versions) are stored on the stack in Java language. So are in C, C++ and in other languages where call-stack as such is implemented. Golang related to local variables is no exception, except…

Except that you can simply return a pointer to a local variable from a function. That was a fatal mistake in C. In case of Go the compiler recognizes that the allocated “object” (I will explain later why I use quotes) is escaping the method and allocates it accordingly so that survives the return of the function and the pointer will not point to an already abandoned memory location where there is no reliable data.

So this is absolutely legal to write:

package main

import (

type Record struct {
	i int

func returnLocalVariableAddress() *Record {
	return &Record{1}

func main() {
	r := returnLocalVariableAddress()
	fmt.Printf("%d", r.i)


What is more you can write functions inside functions and you can return functions just like in a functional language (Go is a kind of functional language) and the local variables around it serve as variables in a closure.

package main

import (

func CounterFactory(j int) func() int {
	i := j
	return func() int {
		return i

func main() {
	r := CounterFactory(13)
	fmt.Printf("%d\n", r())
	fmt.Printf("%d\n", r())
	fmt.Printf("%d\n", r())

Function return values

Functions can return not only one single value, but multiple values. This seems to be a bad practice if not used properly. Python does that. Perl does that. It can be of good use. It is mainly used to return a value and a ‘nil’ or error code. This way the old habit of encoding the error into the returned type (usually returning -1 as error code and some non-negative value in case there is some meaningful return value as in C std library calls) is replaced with something much more readable.

Multiple values on the sides of an assignment is not only to functions. To swap two values you can write:

  a,b = b,a

Object Orientation

With closures and functions being first class citizens Go is at least object oriented as JavaScript. But it is actually more than that. Go lang has interfaces and structs. But they are not really classes. They are value types. They are passed by value and wherever they are stored in memory the data there is only the pure data and no object header or anything like that. structs in Go are very much like they are in C. They can contain fields, but they can not extend each other and they can not contain methods. Object orientation is approached a bit different.

Instead of stuffing the methods into the class definition you can specify when you define the method itself which struct it applies to. Structs can also contain other structs and in case there is no name for the field you can reference it by the type of it, which becomes its name implicitly. Or you can just reference a field or method as they belonged to the top struct.

For example:

package main

import (

type A struct {
	a int

func (a *A) Printa() {
	fmt.Printf("%d\n", a.a)

type B struct {
	n string

func main() {
	b := B{}
	b.A.a = 5
	fmt.Printf("%d\n", b.a)

This is almost or a kind of inheritance.

When you specify the struct on which the method can be invoked you can specify the struct itself or a pointer to it. If the method is applied to the struct then the method will access a copy of the caller struct (this struct is passed by value). If the method is applied to a pointer to the struct then the pointer will be passed (passed by reference kind of). In the latter case the method can also modify the struct (in this sense the structs are not value types, since value types are immutable). Either can be used to fulfill the requirement of an interface. In case of the example above Printa is applied to a pointer to the struct A. Go says that A is the receiver of the method.

Go syntax is also a bit lenient about structs and pointers to it. In C you can have a struct and you can write b.a to access the field of the struct. In case of a pointer to the structure in C you have to write b->a to access the same field. In case of a pointer b.a is a syntax error. Go says that writing b->a is pointless (you can interpret this literally). Why litter the code with -> operators when the dot operator can be overloaded. Field access in case of struct and, well field access through pointers. Very logical.

Because the pointer is as good as the struct itself (to some extent) you can write:

package main

import (

type A struct {
	a int

func (a *A) Printa() {
	if a == nil {
		fmt.Println("a is nil")
	} else {
		fmt.Printf("%d\n", a.a)

func main() {
	var a *A = nil

Yes, this is the point as a true hearted Java programmer you should not freak out. We did call a method on a nil pointer! How can that happen?

Type in in the variable and not the object

This is why I was using quotes writing “object”. When Go stores a struct it is a piece of memory. It does not have an object header (though it may, since it is a matter of implementation and not the language definition, but it reasonably does not). It is the variable that holds the type of the value. If the variable type is a struct then it is known already at compile time. If this is an interface then the variable will point to the value and the same time it will also reference the actual type it is having the value for.

If the variable a is an interface and not a pointer to a struct you can not do the same: you get runtime error. (Addition: As theo pointed out in his comment this is because the pointer variable does not have the type and Go runtime does not know which implementation of the polimorphic method to call. However you can have an interface variable being nil and still holding the reference to a specific type as theo shows in the example.)

Implementing interfaces

Interfaces are very simple in Go, and the same time very complex, or at least different from what they are in Java. Interfaces declare a bunch of functions that structs should implement if they want to be compliant with the interface. The inheritance is done the same way as in case of structs. The strange thing is that you need not specify in case of a struct that it implements an interface if it does. After all it is really not the struct that implements the interface, but rather the set of functions that use the struct or a pointer to the struct as receiver. If all the functions are implemented then the struct does implement the interface. If some of them are missing then the implementation is not complete.

Why do we need the ‘implements’ keyword in Java and not in Go? Go does not need it because it is fully compiled and there is nothing like a classloader that loads separately compiled code during run-time. If a struct is supposed to implement an interface but it does not then this will be discovered during compile time without explicitly classifying that the struct does implement the interface. You can overcome this and cause a run-time error if you use reflection (that Go has) but the ‘implements’ declaration would not help that anyway.

Go is compact

Go code is compact and not forgiving. In other languages there are characters that are simply useless. We got used to them during the last 40 years since C was invented and all other languages followed the syntax, but it does not necessarily mean that it is the best way to follow. After all we all know since C that the ‘trailing else’ problem is best addressed using the { and } around the code branches in the ‘if’ statement. (May be Perl was the first mainstream C-like syntax language that requested that.) However if we must have the braces there is no point to enclose the condition between parentheses. As you could see in the code above:

	if a == nil {
		fmt.Println("a is nil")
	} else {
		fmt.Printf("%d\n", a.a)

there is no need and Go does not even allow it. You may also notice that there are no semicolons. You can use them, but you need not. Inserting them is a preprocessing step on the source code and it is very effective. Most of the time they are clutter anyway.

You can use ‘:=’ to declare a new variable and assign a value of it. On the right hand side the expression defines the type usually, so there is no need to write ‘var x typeOfX = expression‘. On the other hand if you import a package, assign a variable that you do not use afterwards: it is a bug. Since it can be detected during compile time it is a code error, compilation fails. Very smart. (Sometimes annoying when I import a package that I intend to use, and before referencing it I save the code and IntelliJ intelligently removes the import, just to help me.)

Threads and queues

Threads and queues are built into the language. They are called goroutines and channels. To start a goroutine you only have to write go functioncall() and the function will be started in a different thread. Although there are methods/functions in the standard Go library to lock “objects” the native multi-thread programming is using channels. Channel is a built-in type in Go that is a fixed size FIFO channel of any other type. You can push a value into a channel and a goroutine can pull it off. If the channel is full pushing blocks and in case the channel is empty the pull is blocking.

There are errors, no exceptions. Panic!

Go does have exception handling but this is not supposed to be used like in Java. Exception is called ‘panic’ and this is really to be used when there is some real panic in the code. In Java term it is similar to some throwable that ends with ‘…Error’. When there is some exceptional case, some error that can be handled this state is returned by the system call and the application functions are expected to follow similar pattern. For example

package main

import (

func main() {
	f, err := os.Open("filename.ext")
	if err != nil {
	defer f.Close()

the function ‘Open’ returns the file handler and nil, or nil and the error code. If you execute it on the Go Playground (click on the link above) you get the error displayed.

This is not really fitting the practice we got used to when programming in Java. It is easy to miss some error condition and write

package main

import (

func main() {
	f , _ := os.Open("filename.ext")
	defer f.Close()

that just ignores the error. It is also cumbersome to check the possibility of error at each and every system or application call that may return error when we are interested in a longer chain of commands if any of those produced error and we do not really care which one.

No finally, defer instead

Closely coupled with the exception handling is the feature that Java implements with the try/catch/finally feature. In Java you can have code that is executed in a finally code no matter what. Go provides the keyword ‘defer’ that lets you specify a function call that will be invoked before the method returns even if there is/was a panic. This is a solution to the problem that gives you less options to abuse. You can not write arbitrary code to be executed deferred only a function call. In Java you can even have a return statement in the finally block or see a mess trying to handle the situation when the code to be executed in the finally block may also throw exception. Go is prone to that. I like that.

Other things…

that also may seem weird at first are like

  • public functions and variables are capitalized, there are no keywords like ‘public’, ‘private’
  • source code of libraries are to be imported into the source of the project (I am not sure I understood that properly)
  • lack of generics
  • code generation support built into the language in forms of comment directives (this is really a wtf)

In general Go is an interesting language. It is not a replacement for Java even on a language level. They are not supposed to serve the same type of tasks. Java is enterprise development language, Go is a system programming language. Go, just as well as Java, is continuously developing so we may see some change in that in the future.


I was working five years in telecom industry where service availability was God. We had to reach five nines, that is 99.999% percent of the time the service had to work.

Just a simple calculation 99% availability means that the service may be out of service 3 and half day per year. 99.9% means an outage period close to 9 hours. 99.99% means barely an hour and 99.999% five minutes. Is it okay if the phone is out of service at most 5 minutes a year? Certainly. How about your online banking interface? How about a pace maker?

How many 9s do we need?

The point is that you should not aim five nines (or any other availability value) if you do not know why you need that. The bottom line is, as always money. To get to a level of availability has a cost label attached. The more nines you need in your uptime number the more cost you have. The latter nines costs exponentially more. On the other side you have the income, the reputation and all other things that count as money value and are adversely affected by downtime.

Telecom invests a lot of money to get to five nine. Does it pay off? If we only count the lost revenue during the downtime (people can not call and thus do not pay for the talk) then it does not. If we count the reputation, lost customers churning to competition then maybe. If we consider emergency calls: definitely.

Telecom has its values established long time ago and the five nines came from common knowledge distilled during a long time. When you design a service for the enterprise or for the public you do not have that. You have to assess what is worth doing.

Ten years ago I was studying economy. A friend was also studying there and at one of the micmac (mixed micro and macro economy subject) exam he barely passed, though he was usually performing excellent. Being shocked by the unexpected low performance the professor asked him about it. He said: “I was not only studying but also following in practice what you taught us. Invest no more than what is needed to reach the goals. Any more invenstment is wasted.”

Assume for now that we assessed the costs and benefits and we decided we need X nines.

Is more always better?

But how about accidental reaching more uptime than needed? Operation wasted money, invested too much into availability. This is certainly not good. It may also happen that by time small investments (e.g.: continous improvement of personnel, new technologies) lead to better uptime. If it costs nothing the higher uptime is extra gift. But if there is a significant difference between the aimed availability and the actual, the investment was definitely oversized. What will prevent operation to aim higher than what financially feasible is?

It is a difficult organizational question. This is not simply put money in on one end of the tube and get availability on the other. You can invest in many different things that lead to higher availability. You can educate your support people. You can buy higher quality, larger MTBF harware. You can invest in software quality. Some of these have lower cost others cost a lot. If operation reaches in practice higher availability than needed then they wasted money. But it is hard if not impossible to tell which money.

Measure the people performance on system uptime?

Should you measure your operation people on uptime? Certainly. That is a core competency they have: provide the aimed uptime. If the operation does not get the required uptime there will be consequences. You have to assess the reasons, design changes in the system, in the policies, in management hierarchy, but certainly something is to be changed. If there is no change the availability remains low.

If there are no consequences of underperformance on people certainly there will be on the company.

Should you incentive the higher than aimed uptime? Obviously no. May be not that obviously, but certainly: no. If you incentive then they will be motivated reach the goal. If they are motivated to reach something the company does not need they will spend company money to reach that. If you incentive anyone for getting X they will get X. Simple feedback loop. Simple. Ok. But if you do not incentive higher than needed availability then …

should you punish higher availability?

If people get punished for higher availability, operation will still be motivated to spend extra money to get higher availability and ruin it to the required level by means that they can control. (Simply switch off service “illegally” or claiming maintenance.) Even if you do not punish them, they are still motivated to spend extra money just to be safe. We get to the mix of incentives and punishments controlling quality and budget and companies sometime end up with extremely complex motivational schemes.

This dilemma is nothing special. This is a very general management topic. You can not measure what you really want to achieve in your organization. In case of operation you can not measure that oepration is spending the money the most possible wise way and deliver services reliably the level business need. You can not measure it simply because it can not be defined what most wise way is.

What we can do is measure something that is somehow related to what we really need. We start to measure X. The management problem is that if you measure X people will deliver X. So what is the solution? Measurement and culture. We know what the measurements are, we aim the direct goals we are measured on but perform the strategic, tactic and everyday tasks keeping an eye on company goals. That is the culture part. Without culture we are only robots, and robots don’t do good work.


Random Ideas about Code Style

Some of the sentences of this article are ironic. Others are to be taken serious. It is up to the reader to separate them. Start with these sentences.

How long should a method be in Java?

This is a question I ask many times during interviews. There is no one best answer. There are programming styles and different styles are just different and many can be ok. I absolutely accept somebody saying that a method should be as short as possible, but I can also accept 20 to 30 lines methods. Above 30 lines I would be a bit reluctant.

“When I wrote this code only God and I understood it. Now only God does.”
Quote from unknown programmer. Last quarter of the XX. century.

The most important thing is that the code is readable. When you write the code you understand it. At least you think you understand what you wanted to code. What you actually coded may be a different story. And here comes the importance of readability as opposed to writeablity.

When you refactor a code containing some long method and you split up the method into many small methods you actually create a tree structure from a linear code. Instead of having one line after the other you create small methods and move the actual commands into those. After that the small methods are invoked from a higher level. Why does it make the code more readable?

First of all, because each method will have a name. That is what methods have and in Java we love camel cased talking names.

private void pureFactoryServiceImplementationIncomnigDtoInvoker(IncomingDto incomingDto){

But why is it any better than inlining the code and using comments?

// pure factory service implementation incoming dto invoker

Probably that is because you have to type pureFactoryServiceImplementationIncomnigDtoInvoker twice? I know you will not type it twice. You will copy paste it or use some IDE auto-complete feature and for that reason the type replacing ‘Incoming’ to ‘Incomnig’ does not really matter.

When you split up the code into small methods the names are a form of comment.

Very much like what we do in unit tests using JUnit 4.0 or later. Old versions had to start the test methods with the literal test... but that was not a good idea. It was discovered long time ago. (I just wonder when Go will get there.) These days Groovy (and especially spock) lets us use whole sentences with spaces and new lines as method names in unit tests. But those method names fortunately should not be typed twice. They are listed and invoked by Junit via reflection and thus they really are what they really are: documentation.

So then the question still is: Why is tree structure better than linear?

Probably that is how our brains work. We look at a method and see that there are two-three method calls in that. There can be a simple branch or loop structure in it, perhaps one nested to the other but not much deeper than that. It is simple and if method names are selected well (I mean really in a good, meaningful and talking way), they are easy to understand, easy to read.

The we can, using the navigational aid of the IDE go to the methods and we can concentrate on the limited context of the method we are looking at. There is a rough rule:

You should be able to understand what a method does in 15 seconds.

If you stare at the method longer and you still have no idea what the method does it means it is too complex. Some people are better apprehending the structure of the code, others are challanged in that. I am in the latter group, so when I review code I many times prefer smaller and simpler methods. I refuse the code to be merged or I refactor it myself depending on the role, the actual task I perform. Juniors I work with think that I am strict and picky. The truth is I am slow. The complexity of the code should be compatible with the weakest chain: any one of the team (including imaginable future maintainers of the next coming 20 years till the code is finally deleted from production) should understand and maintain the code easily.

Many times looking at git history I see refactoring ping-pong. For example the method

Result getFrom(SomeInput someInput){
  Result result = null;
  if( someInput != null ){
    result = someInput.get();
  return result;

is refactored to

Result getFrom(SomeInput someInput){
  final Result result;
  if( someInput == null ){
    result = null;
    result = someInput.get();
  return result;

and later the other way around.

One is shorter, while the other one is more declarative. Is the repetitive refactoring back and forth a problem? Most probably is, but not for sure. If it happens only a few times and by different people then this is not something to worry about too much. When the code gets refactored the developer feels the code more attached to him/herself. A more “it is my code” feeling, which is important. Even though a good developer is not afraid to touch and modify any code. (what could happen? test fail? so what? test? what test?) Note that not all developers are good developers. But what is a good developer after all? It is relative. There are better developers and there are not so good. If you see only good developers who are better than you, then probably you are lucky. Or not.