# Upgrade to Java non-LTS version

There was a bug discovered in Java 9

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

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 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$.

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.

# Comparing Golang and Understanding Value Types Vilnius DevDays Video

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!

# Comparing Golang and understanding Java Value Types

I start to talk about

Comparing Golang and understanding Java Value Types

The talk compares the memory model of the Go programming language to the memory model of Java. This comparison will help Java developers understand the planned Java 10 feature: Value Types. The talk will describe how these are implemented in Go, and why they so much needed for the Java language. At the end of the presentation, the audience will also understand why Value Types cannot be extended, immutable and passed always by value.
This talk is very lucrative for the audience because it is about Go language as well as a future of the upcoming Java version that is not available yet. Both are a gem for the audience.

right now.

You can look at the slides at https://github.com/verhas/compare-go-java-devdays2018-peter-verhas

# Prevent Hacking with Modules in Java 9

I start to talk about

Prevent Hacking with Modules in Java 9

Before Java 9 there was a lot of room to do tricky things mainly using reflection. Some of these possibilities were even considered as security holes. With the advent of Java 9, the module systems close these secret doors in Java runtime library and also allows library developers to do the same for their libraries.
The presentation will demonstrate some shocking and funny examples what you could do using Java 8 and then tries to do the same obviously failing using Java 9.

right now.

You can look at the slides at https://verhas.github.io/preventHack-J9-devdays2018-peter-verhas/#/

# DevDays Vilnius 2018

Starting today I participate DevDays in Vilnius for the whole week.

Come and see me on May 24, 2018, in Hall 2 at 14:00 and also at 15:55.

I will talk about

14:00 Prevent Hacking with Modules in Java 9 and
15:55 Comparing Golang and Understanding Java Value Types

https://devdays.lt/peter-verhas/

https://devdays.lt/

# Comparing Golang and understanding Java Value Types

Slides and recorded sound of the talk at W-JAX 2018 Mainz conference.

# Java getting back to the browser?

This article talks about WebAssembly and can be read to get the first glimpse of it. At the same time, I articulate my opinion and doubts. The summary is that WebAssembly is an interesting approach and we will see what it will become.

# Java in the Browser, the past

There was a time when we could run Java applets in the browsers. There were a lot of problems with it, although the idea was not total nonsense. Nobody could tell that the future of browser programmability is not Java. Today we know that JavaScript was the winner and the applet as it is deprecated in Java 9 and is going to be removed from later Java versions. This, however, does not mean that JavaScript is without issues and it is the only and best possible solution for the purpose that a person can imagine.

JavaScript has language problems, there are a lot of WTF included in the language. The largest shortage, in my opinion, is that it is a single language. Developers are different and like different languages. Projects are different best solved by different programming languages. Even Java would not so immensely successful without the JVM infrastructure supported by so many different languages. There are a lot of languages that run on the JVM, even such a crap as ScriptBasic.

Now you can say that the same is true for the JavaScript infrastructure. There are other languages that are compiled to JavaScript. For example, there is TypeScript or there is even Java with the GWT toolkit. JavaScript is a target language, especially with asm.js. But still, it is a high level, object-oriented, memory-managed language. It is nothing like a machine code.

Compiling to JavaScript invokes the compiler once, then the JavaScript syntax analyzer, internal bytecode and then the JIT compiler. Isn’t it a bit too many compilers till we get to the bits that are fed into the CPU? Why should we download the textual format JavaScript to the browser and compile it into bytecode each time a page is opened? The textual format may be larger, though compression technologies are fairly advanced, and the compilation runs millions of times on the client computer emitting a lot of carbon into the air, where we already have enough, no need for more.

(Derail: Somebody told me that he has an advanced compression algorithm that can compress any file into one bit. There is no issue with the compression. Decompression is problematic though.)

# WebAssembly

Why can’t we have some bytecode based virtual machine in the browser? Something that once the JVM was for the applets. This is something that the WebAssembly guys were thinking in 2015. They created WebAssembly.

WebAssembly is a standard program format to be executed in the browser nearly as fast as native code. The original idea was to “complement JavaScript to speed up performance-critical parts of web applications and later on to enable web development in other languages than JavaScript.” (WikiPedia)

Today the interpreter runs in Firefox, Chromium, Google Chrome, Microsoft Edge and in Safari. You can download a binary program to the browser and you can invoke it from JavaScript. There is also some tooling supporting developing programs in “assembly” and also on higher level languages.

## Structure

The binary web assembly contains blocks. Each block describes some characteristics of the code. I would say that most of the blocks are definition and structure tables and there is one, which is the code itself. There is a block that lists the functions that the code exports, and which can be invoked from JavaScript. Also, there is a block that lists the methods that the code wants to invoke from the JavaScript code.

The assembly code is really assembly. When I started to play with it I had some nostalgic feeling. Working with these hex codes is similar to programming the Sinclair ZX80 in Z80 assembly when we had to convert the code manually to hex on paper and then we had to “POKE” the codes from BASIC to the memory. (If you understand what I am talking about you are seasoned. I wanted to write ‘old’ but my editor told me that is rude. I am just kidding. I have no editor.)

I will not list all the features of the language. If you are interested, visit the WebAssembly page. There is a consumable documentation about the binary format.

There are, however, some interesting features that I want to talk about to later express my opinions.

### No Objects

The WebAssembly VM is not an object-oriented VM. It does not know objects, classes or any similar high-level structures. It really looks like some machine language. It has some primitive types, like i32, i64, f32, f64 and that it is. The compiler that compiles high-level language has to use these.

### No GC

The memory management is also up to the application. It is assembly. There is no garbage collector. The code works on a (virtually) continuous memory segment that can grow or shrink via system call and it is totally up to the application to decide which code fragment uses which memory address.

### Two Stacks

There are two stacks the VM works with. One is the operation stack for arithmetic operations. The other one is the call stack. There are functions that can call each other and return to the caller. The call sequence is stored in a stack. This is a very usual approach. The only shortage is that there is no possibility to mark the call stack and purge it when an exception happens. The only possibility to handle try/catch programming structure is to generate code before and after function calls that check for exception conditions and if the exception is not caught on the caller function level then the code has to return to the higher level caller. This way the exception handling walks through the call stack with the extra generated code around each function call. This slows down not only the exception handling but also the function calls.

There is no threading in WebAssembly.

## Support, Tooling

The fact that most of the browsers support WebAssembly is one half of the bread. There have to be developer tools supporting the concept to have code that can be executed.

There is an LLVM backed compiler solution so technically any language that is compiled to LLVM should be compilable to WebAssembly and run in the browser. There is a C compiler in the tooling and you can also compile RUST to WebAssembly. There is also a textual format in case you want to program directly in assembly level.

## Security

Security is at least questionable. First of all, WebAssembly is binary, therefore it is not possible, or at least complex to look at the code and analyze the code. The download of the code does not require channel encryption (TLS) therefore it is vulnerable to MITM attack. Similarly, WebAssembly does not support code signature that would assert that the code was not tampered with since being generated in the (hopefully protected) development environment.

WebAssembly runs in a sandbox, just like JavaScript or like Flash was running. Fairly questionable architecture from the security point of view.

You can read more on the security questions in this article.