OK, Java is still free but which version do I use and recommend to my clients?

There remains significant confusion over the licensing and distribution of Java. I know this because I have contributed to this confusion. There is a debate in my college department over which version to use and how updates will be handled. Donald Smith, Sr. Director of Product Management at Oracle in Ottawa, has been kind enough to clear up these issues, probably for the 100th time. The purpose of this brief article is to summarize what I have learned. Before I begin you should read the following posts:


Finished, then let’s begin.

Which Java distribution should I use?

The distribution from https://jdk.java.net always has the latest JDK release including quarterly security updates. This is a tck verified, quality tested, production-ready and open source licensed JDK built by Oracle. As of Java 11 this code base is effectively identical to the non open source licensed Oracle JDK. See the links above for the cosmetic, non-functional differences. You can still download Oracle Java from the Oracle Technology Network (OTN) and use it freely for personal use or training. Still, if you have any concerns or plan to distribute a product based on Java get it from https://jdk.java.net. Have your clients use this as well.

There are many other channels for JDK releases as well from various Linux distributions, hardware vendors, software ISVs and other support providers. Depending on your needs, those may be options as well. More on this later in this document.

What does Long Term Support mean?

Oracle will provide paid support for LTS versions, currently this includes Java 7, 8 and 11, for a significant length of time. Java 11 will have extended paid support until at least 2026. Oracle also provides commercial support for non-LTS releases such as Java 12, with the understanding that those releases are superseded by the subsequent release. For more information, see https://www.oracle.com/technetwork/java/java-se-support-roadmap.html

What does the 6-month cadence of Java releases mean?

Every September and every March a new feature release of Java will be available. These new versions replace the similarly timed updates as experienced in the legacy cadence model such as in Java 8. The last version of 8 is 212 though that number is not the number of distributed versions. Still, there were a lot of versions of 8 some even including new features. The six-month release will now be how patches, fixes and updates will be delivered.

In a brief back and forth on Twitter with Brian Goetz, Java Language Architect at Oracle, he confirmed Java’s commitment to backward compatibility. If you have code you developed in Java 8 then you can rest easy that it will run in Java 13. If you are looking for a new developer for a Java 11 project and they tell you they trained on Java 13 then hire them, they also know Java 12, 11, 10, 9, 8, etc. Java will evolve and will change and that is how it should be.

Isn’t the industry reluctant to use anything other than an LTS version?

Initially yes but only because of misunderstandings and simply wrong statements from people like myself. Just as you used to update your Java 8 when you heard that there was an update so will you update to the next version. The difference is that there is now a regular predictable schedule. This aligns with modern application development practices and other platforms that expect more frequent but manageable updates rather than tectonic shifts every 3-4 years. This will help Java as it continues to be the number one development platform for cloud.

I write web code against an application server, don’t they all need Java 8?

Currently the latest versions of IBM’s Open Liberty and RedHat’s Wildfly run on Java 12 as do others. My informal tests running servlet and JSF applications compiled with Java 12 but with the maven settings for the compiler source and target to 1.8 showed no problems even when the server, Payara, was running on the Java 8 JVM.

What about all those other distributions of Java?

Amazon, SAP, Azul, RedHat, Bellsoft and AdoptOpenJDK, just to name a few, are making distributions of Java available now. The only significant difference between them and what is available from https://jdk.java.net is that these come with installers while https://jdk.java.net only supplies zip/gz files. They are built almost completely from the same source code. Java does not need to be installed on any platform. Just unzip the distribution and configure your application, IDE, or OS to know where it is. All an installer does is unzip and write the optional system configuration to the OS for you. These companies simply provide an alternative to Oracle for paid support or provide a JDK for platforms other than Intel/AMD such as for ARM. There have been alternative distributions of Java for some years now, for example with Red Hat providing an OpenJDK release since 2008 on Java 6.


If you are just starting to code in Java then use the most recent version. If you are using Java then update to the most recent version. If you are worried about possibly running afoul of Oracle licensing or prefer to favour open source then download Java from https://jdk.java.net otherwise download from the OTN.

Written with the assistance of Donald Smith

Book Report: Java by Comparison

      No Comments on Book Report: Java by Comparison

Java by Comparison
Become a Java Craftsman in 70 Examples
Simon Harrer
Jörg Lenhard
Linus Dietz
The Pragmatic Bookshelf
Raleigh, North Carolina

Welcome to my first book report since my high school days. I’ve chosen to write about the book Java by Comparison primarily because it’s the book I wish that I wrote. There are plenty of excellent books on specific frameworks and libraries, but this book doesn’t concern itself with this. Instead, this book with its multiple topics and 70 examples presents the best general approach to coding in any situation. As an instructor in computer programming, I consider how you code is as important as what you code and this book may be the finest example of instruction in how to code.

The book is presented in nine chapters or comparisons, each of which examines one aspect of the programming process. The first comparisons, entitled Start Cleaning Up, is where I found some of what I refer to as best practices when coding. In the introduction to this chapter the authors wrote:

Writing code that’s easy for humans to read and understand is much harder than writing code that compiles.

This is a sentiment I agree with. Submissions from my students that compile and execute are not a guarantee of a good grade. My students will be graduating and joining teams where code will be shared. My favourite section of this first set of comparisons is Ensure Code Symmetry. This is something I see in my students work where multi line switches or if/else statements deal with conditions that are unrelated to each other.

The second set of comparisons is entitled Level Up Your Code Style. One of my favourite topics here is Favor Java API Over DIY.  Sometimes I feel that programmers, by this I usually mean my students, do not spend enough time reviewing the APIs that Java offers. The result is reinventing the wheel. I tell my students that the APIs were written by programmers far more intelligent than myself and them. I even learned a new API in the Collections library called ‘frequency’ in this chapter.

Use Comments Wisely is the third set of comparisons and possibly my favourite. Its is not enough to have comments but rather to have meaningful comments. In the introduction to these comparisons they write about documentation for a smart TV device:

In the section titled “The Record Button,” all it says is, “Starts the recording.” Anyone could figure that much out just by looking at the red Record button! And what happens if you hit the Power button during recording? It doesn’t say.

They then go on to explain the best practices for comments. I especially like the advice to include examples of usage in the comments.

The fourth set of comparisons, Name Things Right, addresses one of my pet peeves, how identifiers are named. I frequently find myself assisting my students in debugging their code. I’ll see an identifier in their code and ask what this class does. The answer is often that its not a class but an instance of a local variable. The same happens when class names begin with a lower-case character.

The fifth set of comparisons is called Prepare for Things Going Wrong. In the section Expose Cause in Variable it is proposed that custom exceptions can best be used to describe errors specific to the code you have written. Rather than try and pick a Java exception class closest to the problem, you should be creating custom classes that can provide the very specific information a programmer may need to understand what has gone wrong.

The sixth set of comparisons, Assert Things Going Right, discusses the best practices for unit testing. It starts with the excellent advice in the section Structure Tests Into Given-When-Then. This will become part of my lectures on unit testing. There is one recommendation where I disagree with the advice to avoid @Before/@BeforeEach. The authors write that explicitly calling an initializing method is cleaner than using the implicit @Before method. On this point we will agree to disagree.

Design Your Objects is the seventh set of comparisons. Here is an excellent discussion called Avoid Returning Null that demonstrates how using instantiated but empty objects are a better return value for indicating a problem rather than just returning null. As Java evolves through its six-month release cycle, I expect two Java constructs to disappear. These are ‘new’ and ‘null’. Until then this set of comparisons is full of excellent advice.

The eighth set of comparisons, Let Your Data Flow, looks at functional notation. While some programmers think of the functional approach as an alternative to object-oriented programmers, the authors point out that the functional style is best used to enhance OOP. Here I see something I tell my students, use a stream rather than a loop when every element must be visited. It is counter intuitive for some new programmers because so much time is spent explaining loops in their courses. I have even suggested to my students that the ‘for each’ syntax should rarely, if ever, be used. Use a stream instead.

The last set of comparisons, Prepare for the Real World, addresses important issues as a project nears or goes into production. There are fewer code examples here. One topic that I am fond of is called Favor Logging Over Console Output. At my school I teach in the final year where students work on a single project for the entire semester. They arrive ready to use System.out.println whenever they want to investigate a specific method. They are shocked to learn that after I present the topic of logging they are now forbidden to ever use console output again. I threaten to come to their workplace and admonish them if I ever hear they used console output for debugging.

One of the many features of this book that makes it a must read and companion for every programmer is the code examples that illustrate each of the book’s concepts and advice. The book shows the before and after for each topic. Examining these practical examples while reading the book significantly enhances the written text. Taken together, the written text and the code examples, makes this book a must read.

I bought this book as an eBook for retail. It was one of my best investments as both a programmer and an instructor. I plan to make it a required text starting in Fall 2019. Let me end with some lines from the last chapter that describe what the authors expect from you after reading the book.

Now, you’re able to

Spot problematic Java code quickly and know how to improve it.
• Recognize common types of bugs and know how to avoid them.
• Explain why one code is clean and another isn’t.

Ken Fogel, Java Champion, Montreal, Quebec, Canada, 2019-02-13