Dealing with the new Java Release Schedule

Oracle has just announced that the End of Support for Java 8 is going to be January 2019. This, in turn, means that every business using Java will need to upgrade for security reasons to the latest version of Java. The new release strategy says that newer versions have a 6-month support and then a new major version of Java is going to be released. In Addition, they are changing the Version naming scheme from SemVer to <year>.<month>Basically allowing Oracle to introduce breaking changes to Java every 6 months. As a business you basically are given the choice:

1. Upgrade Java every 6 Months

If we would go with the first option it already gets strange. At the moment assuming you are currently on Java 8 you would need to directly update to Java 10, as Java 9 Support already has ended. However, you still would first need to update to Java 9 just to see what all does not work anymore due to Java 9 major changes and then move to Java 10. But that is assuming that your 3rd Party libraries also already did the update to the new version. Then in September, you would upgrade to Java 11. A lot of people are going to say, well good then we just do not upgrade now and wait for September to do the upgrade. Yes, you can do that, but that does not really matter as in the following March you anyway would have to upgrade again. Your business needs a new strategy how to deal with the rapid version changes. That is now only supported for 6 months instead of the ~3+ years. Personally, I really like this, as most businesses have the strategy: “Version upgrade? only when hell freezes over” – that only costs money and has no immediate benefits.  Focusing on the short-term impact, neglecting the fact that continuous upgrades are cheaper in the long-term and contain less risk compared to the big bang upgrades. Source: Java Release Roadmap

2. Get Java Advanced licenses (Extended Support)

The alternative is to just get the Java Advanced license. I could not find any information on the Oracle site. Basically, you are paying around 500usd/core (Source), so depending on how many servers you are using you will have to pay a small fortune. At the same time, you are only sidestepping the upgrade issue as you anyway have to upgrade your system every 3 years at least once.

3. Use another Language

Depending on your codebase you may want to look into moving away from Java. If you are starting a project you may want to look into C#, Python or JavaScript (or any other language) Many Java projects are anyway already running for 15+ years and may need a technological overhaul. You could think about switching to micro-services and start replacing a service one by one with another technology. While there are many costs and risks involved switching technologies, *developer training, system stability, continuous support etc. etc.


It really depends on your project and how your business deals with change how you ultimately deal with Release Schedule.  You definitely need a strategy how to approach this problem. The future of Java is unclear. Oracle is promising more rapid improvements of the language.  But there is the possibility that the changes are too drastic so that businesses will stop using the language. Either Java will continue to be one of the most used programming languages or fade into obscurity. The only thing that is certain is that the world of Java is going to be changing significantly in the next couple of years.

HTML: How to control the Form ‘autofill’-autocompetion

Image Designed by Freepik

The ‘autofill’ feature of browsers is a blessing and a curse. The feature enables the browser to reuse the data the user has previously entered in forms. The trouble starts when a form does not fulfill the standard. Then the feature sometimes fills in the wrong information into the fields.

Why does autofill fail?

The standard implemented a feature to group fields. This was created by adding optional ‘8characters at the start of the name’. A field like “first-name” could be interpreted as the group: “first” and autofill-field: ‘name’(=> last name). To correct this you would need to rename the field to ‘given-name‘ as this is defined in the standard. However, if you would test ‘first-name’ in the browser you will discover that autocomplete works without problems. That is because even though it is not in the standard certain aliases are detected correctly. Depending on how the browser interprets the form. If you are not using the standard you basically are telling the browser to guess what the field is and let the browser decide what to autofill.

The Standard Keywords

If you want a pleasant user experience for the visitors of your site then you should take the time to make sure that your form confirms to the standard keywords:

  • “name”
  • “honorific-prefix”
  • “given-name”
  • “additional-name”
  • “family-name”
  • “honorific-suffix”
  • “nickname”
  • “username”
  • “new-password”
  • “current-password”
  • “organization-title”
  • “organization”
  • “street-address”
  • “address-line1”
  • “address-line2”
  • “address-line3”
  • “address-level4”
  • “address-level3”
  • “address-level2”
  • “address-level1”
  • “country”
  • “country-name”
  • “postal-code”
  • “transaction-currency”
  • “transaction-amount”
  • “language”
  • “bday”
  • “bday-day”
  • “bday-month”
  • “bday-year”
  • “sex”
  • “url”
  • “photo”

For Credit Card Information:

  • “cc-name”
  • “cc-given-name”
  • “cc-additional-name”
  • “cc-family-name”
  • “cc-number”
  • “cc-exp”
  • “cc-exp-month”
  • “cc-exp-year”
  • “cc-csc”
  • “cc-type”

To use these keywords with attribute autocomplete. However if the field autocomplete is not set browsers will automatically check the attribute-name. In this example both fields would be detected by autofill as ‘name’:

    <input name="field1" autocomplete="name" />
    <input name="name" />

As a personal preference, I would not set the autocomplete-attribute and simply use the keywords in the field name. This immediately eliminates the need to think of a more suitable name. If you are dealing with a backend you cannot modify I would use the field autocomplete.


Sometimes you need some of these fields multiple times. Let’s say you need a shipping and a billing address.  Then you simply add a prefix to the attribute.

      <input name="billing-street-address" />
      <input name="billing-country" />
      <input name="shipping-street-address" />
      <input name="shipping-country" />

How to disable autofill?

In the rare case that you do not need this feature at all you probably would want to disable it. To do this you have again two options:

Disable globally

Simply add the attribute autocomplete="off to the form-element. You then can re-enable the autofill on an individual component by using autocomplete=on.

    <form autocomplete="off">
        placeholder="disabled Autocomplete" 
        placeholder="enabled for only this input" 

Disable Individual Input

You can disable the autofill feature for an individual component by adding autocomplete="new-password" (This is because Chrome ignores the ‘off’ value)

        placeholder="disabled only for this component"


ReactJS: Tech Demo – Learn Typing

In order to learn ReactJS, I decided to create a small useful tool to learn to type. I just recently had found the typing exercises I did when I was 10, so using that data as a basis I created a small react site. Demo: http://typing.nealbuerger.comSourceCode:

Core Prototype

The prototype only took a look at how to create a single lesson. The lesson was hardcoded and simply took a look at how the lifecycle methods of ReactJs work.

Issue Keyevent Binding I discovered pretty soon that my typing lesson was a quite unusual case for the key event binding for React. I was creating a new type of input field that displayed the old text and change the display depending on the input of new text.

Solution: For my unique case, I added an additional event listener to the document using and passed the information into the react app.

Issue Design Since the goal was to look at various technologies I analyzed ant.designsemantic-ui, and material-ui.

Solution Each of the GUI-Frameworks has their pros and cons. It was a difficult choice, in the end, I created the app using material-ui simply because I liked how it looked. Diving deeper into it how it deals with styles (while incredibly flexible) I would need to get a little more familiar with it. For the next project, I will probably try out something else.

Functional Prototype

To make the app a little more useful, I converted all lessons into a single JSON file. I considered to create a server with a database, but as I only had around 20 lessons and the resulting JSON file was 67kb I decided to simply include the entire JSON file. With more lessons, I needed a lesson overview page and routing. I added react-router and used it with the tools it initially provided. Using react-router can be a little awkward at first. But as soon as you get the hang of it it is a powerful tool.

Improved Functional Prototype

Problem Slow Display of Characters For short lessons react worked great. However, if the lesson had more than ~500 characters the react became extremely sluggish, with even longer texts it took ages only to type a single character. React was re-rendering all components on every keypress.

Solution Basically, the problem was caused by inefficient state management and updating techniques. I added in mobx to deal with all the states and rewrote the core prototype to take advantage of the mobx observers. An additional benefit was to use mobx-react-router which can create a routingStore and lets you avoid the withRouter()stuff.

Current Version

For the last iteration of the project, I refactored the entire code to be more readable and maintainable in the future. For now, I stopped working on this project. It should be only a quick tech demo to show how React code should look like.

Image: Green Typewriter Designed by Freepik