Upgrade to Java non-LTS version
There was a bug discovered in Java 9
and Richard Warburton tweeted about it
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 Shakespearean 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.
1. 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?
2. Costs and benefits
The first and most obvious cost item of the software upgrade is the installation cost: $latex 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 $latex C_t$.
The benefit $latex B$, the reason we do the upgrade is that the software runs better and thus it produces more income $latex \Delta I_u$ for the company and/or needs less maintenance cost $latex C_m$.
$latex 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.
3. Assumptions, simplifications
In case of a Java version upgrade, it is extremely difficult to know the $latex \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 $latex 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 $latex \int_0^T C_m dt$ part is estimated as infinite for large $latex 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 $latex C_i$.
4. 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 $latex 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 $latex 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 $latex C_{iv}(J_8,J_9)$. Similarly, you will have $latex C_{iv}(J_9,J_{10})$ and $latex C_{iv}(J_{10},J_{11})$.
The big question is
$latex 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
$latex \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:
$latex 2 C_{ic} < \Delta C_{iv}$
5. 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.
6. 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.
Comments imported from Wordpress
tamasrev 2018-06-11 16:07:56
I have a question. This might be ignorant, but I need to know if I’m getting it completely wrong.
So, isn’t it a bug that comes with a certain version of openjdk? I mean, a certain version of javac that comes with openjdk. Oracle-s javac doesn’t seem to be affected. Using the latest jvm with an older - but still java 9 jdk (javac) also seems to be okay.
So, please tell me gently: what am I missing?
tamasrev 2018-06-12 12:34:42
Then we should be careful with conclusions like this shows how little java 9 was adopted. This only shows how little openjdk9 was adopted.
Nevertheless, java 9 adoption might be low anyway.
Peter Verhas 2018-06-12 14:31:57
You are absolutely right. Nevertheless, we may safely assume that openjdk9 adoption is proportional with Java 9 adoption. Also, I used the tweet only as an illustration.
Peter Verhas 2018-06-12 09:32:10
Nicolai wrote me a mail:
[blockquote]#> I’ve seen it and want to add an additional cost: The cost to determine for any given migration problem in an LTS-to-LTS migration, which Java version caused it. Imagine how much easier it is to find a solution when googling for "my problem Java 13" as opposed to "my problem". ;) <<<
__#
and I cannot argue with him.
Peter Verhas 2018-06-12 09:30:47
Gently: I do not know. I have not investigated the original bug in any way.
tamasrev 2018-06-13 11:30:58
I don’t know this proportion, it seems to be disproportionate.
Now, that was a lousy two-liner. So sorry. I didn’t mean nitpicking. I just have this machine in my head that sees an implication and then it emulates the possible scenarios.
So, yeah, you’re right too: Low openjdk 9 adoption means low oracle jdk 9 adoption. The oracle jdk adoption is higher than that of the openjdk but anyway.
Comments
Please leave your comments using Disqus, or just press one of the happy faces. If for any reason you do not want to leave a comment here, you can still create a Github ticket.