Category Archives: coding

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.


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

Sublime Text – enabling Eclipse code formatting

My editor of choice for the longest time was emacs, but recently I’ve made the switch to Sublime Text. It’s such a snappy, beautiful, powerful editor. I’ll still use emacs (or vi even, yecch) over a text-only connection, but otherwise, Sublime Text is the bomb.

Sublime Text isn’t an IDE, however; it’s only an editor, and so is missing some bits and pieces that folks used to Eclipse or Netbeans like to have. It makes up for it by being extremely extensible and customizable, using only Python and JSON.

Sublime Text does perform code formatting for you, but most of the world has standardized on using Eclipse for such work. Such is the case for the Apache Accumulo project, which requires code to adhere to formatting rules saved off in an Eclipse-specific XML file. If you are working under Eclipse, this is just fine, and there is even an IntelliJ plugin; otherwise, well, you may have to bounce into Eclipse just to format code. Fortunately, there is an EclipseCodeFormatter plugin that can call out to Eclipse from Sublime Text to format for you.

The easiest way to install the plugin is to first grab Package Control, which is like yum or apt for Sublime Text. Then, use Package Control to install EclipseCodeFormatter.

You do need to manually configure the plugin, as described on its home page (linked above). In order to do it, you will have to up and install Eclipse. Once you do, you can immediately enter the path to the eclipse executable in the plugin configuration. On a Mac (what I use), the configuration file for the plugin is under ~/Library/Application Support/Sublime Text 2/Packages/EclipseCodeFormatter; the patch to Eclipse is something like /Applications/eclipse/eclipse (actually a symlink to inside the .app).

"eclipse_command": "/Applications/eclipse/eclipse",

To create the configuration file the plugin needs, start up Eclipse and create a new Java project. Maybe make a new Java file in there for kicks. Now, go under Preferences → Java Code Style. Under Formatter, follow the link “Configure Project Specific Settings” and enable specific settings for your project. Select the profile you want to use in Sublime Text. (You can also import an XML file if you have it, like Accumulo provides.)

Now do the same thing for Code Templates if you have specific settings for those too. Now, in your project workspace, under the .settings directory, there should be a file “org.eclipse.jdt.core.prefs” file chock full of formatting instructions. Copy that somewhere where you’d like it to live (I put it right with the plugin files). Now you can configure the plugin’s path to the config file to point to that file.

"config_file": "/Users/bhavanki/Library/Application Support/Sublime Text 2/Packages/EclipseJavaFormatter/org.eclipse.jdt.core.prefs",

You’re all set to use the plugin. You can use the Command Palette to invoke the command and format the current buffer. You can also add a keymap entry to turn on a shortcut for it. Under Mac OS X, I found that Control+Shift+F was available:

{ "keys": ["ctrl+shift+f"], "command": "eclipse_format_java" }