# 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

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

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/#/

# Source Code Generation is not Good

The most important statement in this topic before we would even start to discuss anything else is that source code generation is a suboptimal solution. It may be needed and it may be a viable solution, but whenever source code is generated it could have been done some way better. It is just that the environment, the available tools, developers are not fit for the purpose. Let me give some examples.

When you program Java you use Eclipse, IntelliJ or NetBeans. Each of these IDEs is capable of generating hashCode(). What is wrong with it? The language could provide a declarative description of how to compute the function. The hash code depends on the hash code of the fields and the calculation is fairly standard. Why can’t we just define which fields should be taken into account and the language would implicitly provide us with the method? In this case, the language is insufficient for the purpose. I do not say that Java should provide such a feature. Maybe it should, maybe it should not.

In case of setters and getters the case is more prominent. Java needs them and we have to generate them whenever there is a need. Other languages, like C#, Swift or even Groovy support the feature on the language level.

Another example from my practice when I needed several business object classes converted to Map<String,String> with a special format. I created some utility classes that listed the fields using reflection and performed the conversion. This solution, however, was rejected during code review. The code was too complex and later teams who will be responsible for the maintenance may not be able to cope with the code. I could have said that they should hire cleverer people, but that costs more money and they wanted code that is cheap to maintain. The solution was to write extremely similar code for each and every business objects class. It could have been generated if there was any tool that could do that and, which could have been part of the build process, which again increases maintenance cost. In this case, the human environment was insufficient.

Please do not start flame war on this part of the article. This example is partially made up for NDA reasons, and after all it is not the major topic of the article.

# Navigare Necesse Est

The above examples clearly depict that source code generation is a must. We may not like it though, but it is a must. The next question is when to generate code, which phase of the development process?

It is fairly obvious that source code can only be generated before the compilation phase. You can generate source code after the compilation phase, but that is like calling a doctor after the patient is dead: no use. We can generate code during the build process, just before the compilation phase or as part of the editing process. Both have advantages and disadvantages.

## Editing Phase Source Code Generation

When you generate code while you edit the code the code generation does not need to be part of the build process. This means that the rebuild of the code is simpler, there are fewer
potential deviations from the standard build process and thus you are more likely to be able to do it when you work in a restricted enterprise environment. An example is when you use your IntelliJ to generate hashCode(). The generated method is available immediately in the editing environment, and functions like auto-complete will take the generated code into account.

The disadvantage is that the process is triggered manually. The more manual the process is the more room there is for human errors. You create a new field and you forget to update the hashCode() in the class. The generated code also gets into the source code repository that may not be optimal. Source code repository is for the source code and generated source code is not really source-code, is it?

## Build Process Source Code Generation

When you generate the source code during the build process the code generation tool will certainly rely on the last version of the source code. In our example there will not be any field left out from the hashCode() method.

The disadvantage is that the build process is more complex. Your favorite code generation tool may not be available or allowed in the environment you work in. The tools that can be hooked into the build process usually generate whole files. It is not likely that you will generate a hashCode() method into the middle of a class using a tool that runs on the build server in batch mode. Also, you will not have the generated code in your IDE and you may lose some of the code editing support.

Build time source code generation tools are usually also environment specific. You may have a tool that works for Java but does not work for Rust or Python projects.

There is no clear “one is better than the other” decision. Sometimes build time source code generation is better, other purposes are fit better with edit time source code generation. I created tools like Fluflu mentioned in my article “Named parameters in Java“, or Scriapt Java annotation processing tool described in the article “Don’t write boilerplate, use scriapt“. These tools are Java specific and build time executable. They are annotation processors, that hook into the Java compilation process and thus interestingly the IDEs continuous builds also handle them.

# Source Code Generation In-line

This time I want to write about a Python written tool Pyama that can be used to generate code not only for Java but also for Go, Rust, Markdown or just anything else. It is an editing phase tool and it was designed with editing in mind. The major idea was to automate the part of the editing process that can be automated.

## My Demanding Need

The demanding need was my editing the new edition of my book Java 9 Programming by Example published by Packt. The first edition of the book was edited in MS Word and I had to copy paste the source code samples from the IDE. However, book and code development is not a linear work. Sometimes the code was edited and modified after it was copied. It was a huge work to revisit each code sample in the book to see if the latest version is included in the document. I wanted something else, something more automatic. Luckily the second edition that will address Java 11 is edited with a different format that I can convert from Markdown. I edit the text in Markdown and I needed a tool that copies the code samples into the text.

The first idea was to create a tool that converts a .md.pre file that contains markdown and special directives controlling the source code inclusion into .md containing the code snippets. Such a solution, however, would not allow me to see the full rendered document in a Markdown WYIWYG editor. IntelliJ lets me render the markdown document text on the left side of the screen and see the result on the right side, which is a great help when I forget closing a backtick. Thus I decided to create a tool that can copy the snippets into my edited text file. It is also very handy that IntelliJ keeps the file almost all the time saved and reloads it when it is modified on the disk. Therefore I can edit the file in the editor and I can safely edit the file with any external tool. To develop this tool was also a nice Python learning project.

I also wanted to create something that was more general than just fetching snippets from code files and insert them into markdown documents. The outcome was a framework that, by now, has several extensions. One is handling snippets and markdown, others generate Java code (setters, getters, equals, hashCode, constructors, builder methods), handle text macros, execute Python scripts in any code files and so on. These extensions are samples and you can create other extensions with a few lines of Python code. As far as the book writing and Markdown Pyama proved to be an extremely valuable tool.

## Pyama Architecture

When generating code into already existing source files, it is evident that the unit of editing should be something more granular than a file. We should not overwrite a whole file with something new. The tool has to distinguish between the lines that need to be altered, or rather that are allowed to be altered and those that must not be touched. Pyama introduces the notion of a segment when processing files. The tool splits up the source files it works with into segments. Segments contain lines of the text files. Thus a pyama project works with files, each file contains segments and each segment contains lines. The segments of a file make up the whole file. In other words, there are no lines outside of segments. Pyama reads the contents of the files into the memory and then it invokes configured handlers (Python objects) to do whatever they should with the individual segments. When invoked, a handler works with a single segment. It can collect information from it, it can build up data structures to use later and it can read and modify the lines that are in the segment. This way the code of a handler is extremely simple, because it does nothing else but processes a list of strings and it does not need to care for anything else.

To decide where a segment starts an ends pyama asks the handler objects for regular expressions to identify lines that start and end segments. Different handlers may work with different segments and they may have different start and end patterns.

The segments in all files are processed a few times invoking the handlers in several passes. For example, the snippet reader may collect the code snippets from the configured source files into a snippet store where each snippet is identified with a name. In the next pass, the snippet writer handler looks at segments that start with a line referencing a named snippet and it replaces the lines of the segment with the current version of the collected snippet.

The snippet reader says that each line that contains START SNIPPET starts a new segment and such a segment lasts till a line containing END SNIPPET or till the end of the file. Then the code

// START SNIPPET main_java
System.out.println("Hello, world!");
// END SNIPPET


will collect a snippet that contains the code sample. The snippet writer manages segments that start with a line that contains USE SNIPPET and the name of the snippet and end with a line containing END SNIPPET. If there is a line in a file that the snippet writer processes that reads

USE SNIPPET main_java
System.out.println("Hello, outdated string world!");
END SNIPPET


it will replace it with

USE SNIPPET main_java
System.out.println("Hello, world!");
END SNIPPET


The lines with the USE SNIPPET and END SNIPPET remain in the code, but in most formats, it is possible to hide them into some comment field that the output (HTML renderer, or Java compiler) will ignore.

This is only the tip of the iceberg of this code generation, text processing tool. There are handlers that can number the snippet lines, trim the code, skip certain lines that may not be interesting for the printout, apply regular expression search and replace, or even execute small Python scripts that can create the segment text.

For example the following code

/* PYTHON SNIPPET xxx
fields = ["String name", "String office", "BigDecimal salary"]
print("    public void setParameters(",end="")
print(", ".join(fields), end="")
print("){")
for field in fields:
field_name = field.split(" ")[1]
print("        this." + field_name + " = " + field_name + ";")
print("        }")

print("""
public Map getMap(){
Map retval = new HashMap();\
""")
for field in fields:
field_name = field.split(" ")[1]
print("        retval.put(\""+field_name+"\", this."+field_name+");")
print("        return retval;\n        }")

END SNIPPET*/

//USE SNIPPET ./xxx
public void setParameters(String name, String office, BigDecimal salary){
this.name = name;
this.office = office;
this.salary = salary;
}

public Map getMap(){
Map retval = new HashMap();
retval.put("name", this.name);
retval.put("office", this.office);
retval.put("salary", this.salary);
return retval;
}
//END SNIPPET
}


can easily be changed to contain another field, just adding to the type and the name of the field to the array named fields. In real life examples the source printing code would be in some external file and imported, and probably the generated code would also be more complex than this sample. This code, however, enlightens that with minimal Python knowledge such manual tasks can be automated.

Please feel free to try and use pyama available from GitHub.

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