This post was first published on JAXenter.

Last year, our most popular blog post by far was The Legacy Developer’s Guide to Java 9. With Java 10 around the corner, it was natural for us to consider writing up a “Legacy Developer’s Guide to Java 10.” However, in researching the topic, it became clear that Java 10 just isn’t that exciting, and that there’s really no reason for legacy developers to worry about how they can take advantage of it or even whether they need to think about it.

The problem with Java 10 reflects broader issues relating to software release cadences in Java and beyond. I would suggest that this is a consequence of the accelerated Java release cadence that Oracle announced last year. It used to be that new Java releases came out every couple of years – enough time to implement a checklist of significant new features. The release managers had to juggle a number of factors, including providing enough time to get enough features completed and into the release, and not taking so much time that people got frustrated waiting for the new release. Inevitably, some overly ambitious features would be postponed to a later release or discarded.

The new Java release cadence calls for two releases a year.  With only six months between releases, can anybody be surprised that a new Java version will consist entirely of small-bore incremental improvements?  And when it does, can anybody be surprised when nobody seems particularly excited by it?

Java’s not the only technology that’s succumbed to the pitfalls of accelerated release cadences. Microsoft is now pushing out new updates to Visual Studio several times a year. New versions of .NET (Framework, Core, and Standard) are pushed out at an accelerated pace. And most of those releases are incremental, and relatively few developers will care about any particular release.

I think part of the problem is that the emergence of Software as a Service (SaaS) has caused expectations to shift. With SaaS, it’s easy to push a new feature or a new fix to the entire development community whenever it’s convenient to do so – no need to wait for a critical mass of changes before issuing a release. People have started to expect the same pace of release in shrink-wrapped software, but I think that’s a mistake.

A few years ago, the development community started discussing something called “developer fatigue.” At the time, the cause was identified as the rush of new open-source technologies were becoming available to the public. This is still a problem, but a growing cause of developer fatigue is this accelerated release cadence of Java, Visual Studio/.NET, and other technologies and products. Let’s call it “release fatigue.”

Look, I get it: It took three years after Java 8 for Java 9 to be released, people started getting frustrated, and Oracle got some probably-well-deserved heat. But I think that the pendulum has swung too far in the other direction. With a release every six months, we’ll get new releases loaded with minor new features that few are ready for, and that few care about. If the old two-year cycle is too slow, why not relieve release fatigue by splitting the difference and having a one-year cycle?

What’s New in Java 10

Despite my opinions about the cadence of releases, Java 10 is here, and I would be remiss not to review them. So, here goes…

There are a dozen new features in Java 10, but only one big developer-facing feature: local-variable type inference. C# developers have been familiar with this feature for a number of years: rather than declaring local variables to be of a particular type, simply declare them as var and allow the compiler to figure it out and then enforce the type rules. In C#, some people use it and some people don’t. I personally don’t use this feature as I find it leads to code that’s difficult to read and understand, and I have no problem doing the additional typing to declare variables to be of a particular type – it’s an ingrained habit. Java developers who feel the same way won’t use this new feature, but others will. If you’re a legacy developer and want to use this new feature, you clearly won’t be able to use it in legacy code, but only in new Java 10-targeted code that will have to be tucked into the Java 10-versioned section of a multi-release JAR file (as introduced in Java 9).

The other two developer-facing features are highly specialized, and most developers will have no need to use them or will even be aware that they exist. One is an enhanced set of Unicode APIs, and the other is an incremental change to the version-numbering schema. Java 9 had its own change to the version-numbering schema, which was actually a breaking change for those who used the versioning API, but this new change will likely not break any existing code.

The remaining new features are mainly under the hood, where few developers will encounter them: garbage-collection support (here and here), changes to the run-time implementation of classes and threads, changes to heap implementations in the JRE to accommodate new memory technologies, and a new just-in-time compiler written in Java. There are also changes in tooling: the javah tool has been removed, and a set of root certificates has been supplied. Finally, the repository for the JDK source has been reorganized.

While each new feature certainly has its constituency, I think it’s fair to say that the typical Java developer, legacy or not, will be underwhelmed by the new features on offer in Java 10. As for “release fatigue,” maybe Oracle and other vendors will come to their senses and have mercy on those of us suffering from it.