Tag Archives: java

The Java versioning situation

It’s been quite a long time since I’ve blogged anything here, but I think I should pick back up again. I enjoy it. It’s not like I’ve been idle for a year plus, so I’ve got a few topics I could talk about here. One that’s sort of been vexing me lately is the new Java versioning cadence.

To be honest, it’s shifted so much over the past few months that I’m not 100% confident I understand it. Where it should stand now is as described in JEP 322, and there it seems as if the ill-advised date-based versioning proposal has been set aside, relegated to the “Alternatives” section. It lingers here and there in things I read, but I’ll just proceed assuming it’s gone.

So basically we’re now in a six-month “feature” (i.e., major) release cadence, and every third release is a long-term support (LTS) release. There are some benefits to having a regular release cadence; there’s always a train ready to leave the station that you can board new features onto. I think that helps motivate the introduction of new language features, because it does away with discussion about “is this worth a new release?” – instead, it flips the question to “which release is this ready for?”

Tokyo 3345

The date-based versioning scheme, yeah, though, wasn’t a fan. I tried not to look at it as a curmudgeon oldster or anything, but I just couldn’t get myself comfortable with it. Maybe I’m too much of a semver fan, although even that doesn’t say you can’t just use the year as the major version number. I just prefer having languages version themselves independently of when they happened to show up.

Even the new scheme has a bit of an issue because that first number in the version string isn’t tied strongly to the introduction of new features or breaking changes. It’s just a one-up counter, every six months. I suppose some Java release in the future won’t have any major changes in it, but that counter will have to bumped anyway. This runs counter to organizations’ expectations that when that first number changes, it’s a big deal.

From my experience, big organizations that doesn’t do tech as their main line of business don’t grok the intricacies of version numbering. Their security teams and IT organizations just devise straightforward rules to follow, and one of those that they learned over the past decades is that when that first version number changes, you have to do a lot more acceptance / security testing before you let it in, because that means there are significant changes to the software. It’s been learned as a message from the vendor that this new release is not just a run-of-the-mill update.

Java doesn’t play by those rules anymore. I can see a (reasonably) paranoid organization balking at this swift change in version numbering. A counterpoint, though, could be browsers like Firefox and Chrome, which bump their numbers up with abandon … and Firefox at least does LTS releases. Hopefully they have served as harbingers for this alternative take on versioning.

Another odd but somewhat logical consequence of this new cadence is that those non-LTS releases of Java go EOL in six months. This makes sense from the language point of view, to motivate customers to stay current, especially for security fixes. But it’s a PITA for a software vendor, such as my employer. When Java 9 came out, should we have embraced it and moved to it as a minimum version for our software? Definitely not. Why?

  • We were just moving up to Java 8 as a minimum, because our software had promised Java 7 as the minimum for our customers. We won’t bump up the minimum Java version without a major release of our own product. Ugh.
  • What could we have done for customers who hadn’t accepted Java 9 yet? It’s not unheard of to wait a year before considering adoption of a major language revision, and Java 9 hasn’t been out a year yet (as of right now).
  • When Java 9 went EOL, what would we do? Declare you need Java 10? We’d be in for another round of testing ourselves, and probably need to cut new (major) releases. And how about those customers, still reeling from the rush up to Java 9?

And that’s the kicker. At the time of this writing, Java 9 has already gone EOL. Today, to be using a supported Java, you should be using either Java 10 or Java 8. Java 9, we hardly knew you.

A root problem here is that the enterprise world, which my employer seeks to support, isn’t yet ready for this cadence. They want stability, and we want to give them stability, so that they can manage risk for operational systems. An end-user application like a browser has a different risk profile than a language running mission-critical applications. For the latter, if the Java version it runs on is working, then it’s best not to touch it except for bug fix releases.

The operating assumption I’m going with nowadays, then, is to essentially ignore the non-LTS releases, for our own sanity and those of our customers. Really, that’s the purpose of an LTS release. If you are in a really fast-moving environment, you can upgrade with the speed you crave; otherwise, stick with the LTS releases and don’t worry about it.

That means that Java 11, coming out in September, is what we care about next, and we’d better gear up soon to test it, for when Java 8 gets yanked away. This will still cause some hand-wringing and fretting. In a way, though, we could use a little motivation to update more quickly. Not so much for the language features (which I’d like to play with), but for the security features.

Thinking about Firefox in particular, I remember it was a big deal when they switched to the Chrome-like versioning cadence. However, their seamless upgrade experience makes it work. The Java language could use something like that, but it needs to bring along with it the experience that moving from one major version to the next is no longer A Big Deal. Hopefully, after a year or two of enterprises being hitched to the new release train, that happens.

Advertisements

The Java logging quagmire

I’ve started working on a new Java project, and it uses the popular SLF4J logging framework. I’ve never really had the opportunity to use it before; I’m mostly a Log4j guy with the occasional foray into Apache Commons Logging. SLF4J is highly similar to both of those other frameworks, but I got a bit confused because a dependency of this project, Apache HTTPClient, uses Commons Logging, and so there was this weird JAR to bridge them in there, and then Logback was around too. It was then that I fully realized what a mess the Java logging ecosystem is. This post attempts to detangle it.

Continue reading