There was a bug discovered in Java 9

https://bugs.openjdk.java.net/browse/JDK-8204322

and Richard Warburton tweeted about it

"+=" duplicates the first part:https://t.co/F8wFtBOz7j

This looks like a pretty nasty bug actually. The fact that this is Java 9 onwards and only spotted now does make me question how many people are using Java 9 in production and how safe it is to migrate to it.

— Richard Warburton🥓 (@RichardWarburto) June 6, 2018

If you look at the twitter thread you can see that following this tweet I had some friendly fencing-bout with Nicolai Parlog about upgrading or not upgrading to non-LTS Java versions for commercial production applications (what a Shakespearian dilemma!). Part of the bouts was about misunderstandings as usually when using a limited communication channel. (Just a side note: I know Nicolai irl, he publishes a lot, a nice guy, great Java expert and in case you follow me on the blog, twitter or just in the street you definitely should also follow him, .. better not in the street, that is creepy.)

Since Twitter is a bit short of characters I decided to collect here my thoughts.

What is the question at all?

For a lot of people, who use a computer and support themselves, install new software the question is obvious: use the latest version! Why would anyone want to use an outdated version of a software? I do not say that their answer is wrong for the situation they are in, but it is not a rationally calculated decision. You can decide based on rations or based on feelings or even random. Your decision may be sufficiently good, though science says that decisions based on well-established reasoning are usually more reliable and more often sufficiently good than other decisions. That is the reason why there are so many divorces.

The well-established reasonings about the upgrades and when to upgrade consider the cost and the benefit of the upgrade. What costs do we have?

Costs and benefits

The first and most obvious cost item of the software upgrade is the installation cost: $C_i$ .

It may be small but it can also be significant when the organization has several servers. The installation has to be tested. The new version of the software may not be compatible with the previous version from which we upgrade and it has to be tested. Proof of the pudding is eating. The testing should be done on the actual application that we use. For example, we may not care about the bug that falsely calculates an x += value expression if our code never uses the += operator. The testing cost is $C_t$ .

The benefit $B$ , the reason we do the upgrade is that the software runs better and thus it produces more income $\Delta I_u$ for the company and/or needs less maintenance cost $C_m$ .

$B = \int_0^T \Delta I_u - C_m dt$

The summing up should be considered from the time of the installation until the time while the software is used.

Assumptions, simplifications

In case of a Java version upgrade, it is extremely difficult to know the $\Delta I_u$ and the best estimate is to model it as zero. That essentially leads us to cost reduction. Estimating the cost reduction we usually ignore the short-term effects and consider only the long-term ones. Using Java 9 instead of Java 8 in a short time period rather increases than decreases the support costs. The support people have to learn the small intricacies of the new version and they are likely to make more mistakes shortly after the upgrade. This is essentially a temporary increase that we could consider to be part of the upgrade cost. In real life, if ever these calculations are performed these costs are not identified and do not get an estimated value. Rather they are ignored lessening the detected cost of an upgrade. This is understandable if you consider that these cost estimations are made by IT people and we love the newest versions and we want to upgrade. (As a demonstration read the Twitter thread.)

In the long run, when we consider the $T$ in the range of 5 to 10 years the maintenance cost is drastically increasing. A few years ago an old friend of mine was offered a year-long contract to maintain RPG application (not the role-playing game, google it, it eas before COBOL) for 400EUR per hour and he refused saying that the little time he has left he wants to spend with the family. (Old I meant literally in his case.) You cannot find a developer who would joyfully jump on the possibility to maintain a Java 6 application and if they accept they will not be shy to ask the price. You will see the same moue on their face when you mention that time age-old Java 8 or Java 9 version.

That means that the $\int_0^T C_m dt$ part is estimated as infinite for large $T$ values and zero for small ones. In layman terms, it implies that sooner or later we have to upgrade. Upgrade necesse est. Vivere non est necesse.

What we have left is the cost of the upgrade $C_i$ .

Upgrade cost

When we consider Java long term and non-long term support versions we have to compare the small steps upgrade process and the three stairs jump climbing from one LTS to the next LTS version.
Every upgrade cost has a constant part $C_{ic}$ . This is the cost of downloading the media, installing on the server, running the tests, managing the meetings, communicating the out-of-service times and so on.

There is another part of the cost that depends on the previous version from which we upgrade, a variable part of the cost $C_{iv}$ . When you upgrade from Java 8 to Java 9 you have to fight each and every compatibility issue that affects your application. Say this is $C_{iv}(J_8,J_9)$ . Similarly, you will have $C_{iv}(J_9,J_{10})$ and $C_{iv}(J_{10},J_{11})$ .

The big question is

$C_{iv}(J_8,J_9) + C_{iv}(J_9,J_{10}) + C_{iv}(J_{10},J_{11}) + 3 C_{ic} < C_{iv}(J_8,J_{11}) + C_{ic}$

It is certain that the variable part of the cost of the upgrade from Java 8 to Java 11 is larger than the same adding up from Java 8 to Java 9 and then from Java 9 to Java 10 and from Java 10 to Java 11. Using the notation for the difference

$\Delta C_{iv} =C_{iv}(J_8,J_{11}) - \big(C_{iv}(J_8,J_9) + C_{iv}(J_9,J_{10}) + C_{iv}(J_{10},J_{11})\big)$

the above question becomes simpler and easier to interpret:

$2 C_{ic} < \Delta C_{iv}$

Interpretation and conclusion

The calculation mainly is playing around with latex and mathematical expressions, and they result in the obvious: if the constant cost of the upgrade that happens three times in one case versus one time in the other case is bigger than the extra cost of the big leap upgrading from Java 8 to Java 11 then you should not upgrade to the intermediate versions. If you work in a big organization with a lot of meetings, lot of administration, which is needed to keep the organization alive, then you do not upgrade for each an every version. If you are a small company, doing things fast and flexible then you will upgrade.

Post Scriptum

Creating the formulas and expressing the calculation in a mathematicized way helps engineers to avoid some mistakes like ignoring some cost that should not be.

Do not think that being small, flexible and fast is always better than big, slow. Both have advantages and disadvantages and both have the place to live in the economy. A small company will never build a railway, a telecom network, or an ocean cruiser. The dinosaurs are extinct but there are whales as well as viruses. You may certainly enjoy more to work for a virus than for a whale.

I have edited the video I recorded during the conference where I presented Comparing Golang and Understanding Value Types. The conference was DevDays Vilnius, the talk was May 24, 2018. The video shows the slides and, just for the sake of completeness and to increase the enjoyment factor, my slender myself presenting in PIP.

I delivered the talk also April, the same year in Mainz at W-JAX and it seems that this talk is doomed. In Mainz, another talk finished sooner and the presenter’s wireless mic was on the same frequency as mine. They forgot to switch it off and coming closer to our room the noise of the coffee break mixed with the signal of my mic.

Here in Vilnius, there was a presentation in the room next to my presentation where apparently there was no air conditioning and all doors and mobile walls were kept open all times. The presentation delivered by Sam Bellen was titled “Channel Your Inner Rockstar with the WebAudio API”. Don’t laugh! It was not funny!