JSR 376, Java 9 Optional, Multi-Release Artifacts, Git Fixup, And Jenv

CodeFX Weekly #17 — 5th of May 2017

Hi everybody,

after last week’s downer we’re back to technical topics. As usual, there’s a lot of Java (Optional, multi-release artifacts, Maven) but further down you will also find a new Git alias, and some comments on Atom syntax themes. The project of the week is also quite awesome...

But before I get to all of that I have a question for you. Now that I’m no longer writing a newsletter for SitePoint about what is going on in the Java community, I wonder whether I should talk about that here. Would that interest you? If you have an opinion, tell me about it in what is possibly the shortest survey ever.

To give you a taste of what to expect you can find two small news items about the ongoing JSR 376 ballot and recent developments on stepwise migration. If you want to read more stories like that, let me know. If you prefer to get your news elsewhere and prefer my random ramblings (which will naturally become a little fewer), let me know as well.

Did you get the point? Let me know!

I send this newsletter out every Friday. Yes, as an actual email. Subscribe!

Java News

The JSR 376 Ballot

Any change of Java (be it the language, the compiler, or the JVM) that goes beyond a mere implementation detail needs to be specified and the mechanism to do that is a Java Specification Requests, JSR. For the module system that’s JSR 376 and last week its public preview ballot opened. If you know as much as I did a few weeks ago you will ask yourself, “What ballot?!”

Every JSR is voted on by the Java Executive Committee, in which 23 companies (e.g. Credit Suisse, Intel, SAP, Twitter), communities (e.g. London Java Community), and individuals (Ivar Grimstad, Werner Keil) are represented. Most JSRs only need a simple majority but anything related to the language, like the module system, needs two thirds of the votes (I didn’t check whether of all votes or just of the cast votes), which might turn out to be too high a hurdle for 376.

I was told the votes are usually cast behind closed doors and only become public once the ballot closes but that’s definitely not the case this time! After the strong criticism by RedHat’s Scott Stark and others, it is no surprise that RedHat voted “no”. This became public when IBM’s Tim Ellison publicly replied to state that IBM would do the same. In a later mail he detailed the rationale behind his vote.

Hazelcast did not cast its vote yet but their representative Chris Engelbert announced (in German) that it is also very likely to be a “no”. The London Java Community seems to be on the fence as well. The most recent member to come out against the proposal was the Eclipse JDT team.

(If you want to read more about the reasons behind the votes without reading all those lengthy mails, have a look at InfoQ’s he-said-she-said summary. If nothing else, read Mark Reinhold’s open letter, which he just published on his blog.)

With somewhere between three and five confirmed “no”s, JSR 376 is already half way to being voted down. Wow. What happens then?

In that case the spec lead, Mark Reinhold, gets 30 days to improve the proposal and initiate another vote. As I see it, though, the perceived deficiencies that are publicly cited as reasons for voting “no” can not really be addressed in that time frame. It is of course possible that some voters want to use the leverage of pending failure to get a few more concessions but if we take them by their word, most second vote’s should be “no” as well.

I’ll speculate further after the first ballot closes on May 8th. Looks like I found a topic to write about next week.

Automatic Modules and Module Names

So much for “a short news item”… I’ll push the commentary about the automatic module name news into the next weekly and leave you with links to Mark Reinhold’s recent mail.

Java Code


You may have heard about Optional’s new method or, which takes a Supplier<Optional<T>>. If called on an empty Optional the supplier is executed and the created Optional returned - this way you can "recover" from an empty Optional.

I was recently writing some code where I wanted to log a message if the Optional was empty. I found the evolution rather interesting and am sure you'll get it without moderation...

Artifacts For Java 8 And 9

Imagine the project you’re working on uses types from, say, the package javax.xml.bind and you're looking into Java 9 compatibility. It's a standardized API so everything should be peachy, right? Well, obviously not or I wouldn't be asking this.

For reasons left unexplored here and now, modules containing Java EE APIs (like java.xml.bind) are not resolved by default, so your hypothetical project would fail to compile and run on Java 9. The solution is simple: Use the command line flag --add-modules to add the module java.xml.bind and you're good to go.

That suddenly stops being a good solution when your project is a library, though, because then you have to tell your users to add that flag and that is inevitably going to lead to bug reports, complaints, and angry comments. Again, a solution pops up that is deceptively simple: Just create a module for your lib (maybe that was even your first idea) and have the declaration say it requires java.xml.bind.

Oh, you want your library to continue working on Java 8? Then you’re in the position that lead to this StackOverflow question and eventually my answer. In short: it’s possible but not easy. (But by now you already know it never is, right?)

Excluding Maven Plugin Dependencies

On an illustrious hike through Java 9, JAXB, and Maven territory, I ended up with the need to exclude a Maven plugin’s dependency from the build process. I was sure I once read it was possible and indeed the <exclusions> tag promised exactly what I was looking for.

The usual phases of software development ensued: hope, activity, confusion, googling, destitution, hopeless googling, StackOverflow question, realization, anger, acceptance (with undercurrents of anger).

Turns out, <exclusions> don't work on direct dependencies. Err, what? Yes, you got that right: If the Plugin Juicer depends on Mango, which depends on Stone, I can exclude Stone from the process but not Mango. Makes sense for juice but not so much for Maven. So an issue was created and maybe at some point I can enter the final phase: catharsis.


As you can tell by shortcuts like git patch, git ammend, and git rebase-unpushed I'm sold on the idea of creating a clean Git history (which was recently likened to writing on toilet paper but who are you to judge me for my hobby?!). As such I grew increasingly annoyed with git commit --fixup=<hash>.

Unfortunately the solution is not to simply alias fixup with commit --fixup= because then the final command contains a space in the wrong place (--fixup= <hash>) and doesn't work. Git aliases can execute random commands but as usual I didn't know how exactly to go about it. In the end I opted for this answer and went with:

fixup = "!git commit --fixup=$1 #"`

There was some good reason for that finishing hash but I already forgot… I don’t care, though, because now I can be all git fixup <hash>.

Atom Syntax Highlighting

I’m using Atom a lot right not. Like, a lot: formerly SitePoint editing, the book, slides, this newsletter, other articles I write, documentation… all of that flows through Atom. A little uncommon for me, I didn’t invest too much time into customizing it and have just used the Atom themes (dark when at home, light when on the road or outside).

Recently I craved a little more color and before looking into downloadable themes, tried the other built-in pair: One Dark/Light. Now I feel stupid. This is so much better and was always just a click away. As I said, stupid…

I also grew sick of manually switching the theme back and forth and started looking into writing a plugin. That’s actually fairly easy and after googling for JavaScript trivialities like how to check whether a string contains a substring, I cobbled something together. Works like a charm on Atom Dark/Light but fails miserably in One — of course. I wanted to create an issue but that’s way to much work to squeeze in somewhere, so I’ve put it off.

As usual when doing some JavaScript (which happens about every two months), I was surprised how little it took to get something done. That’s it? Just a couple lines?

Project Of The Week

This week’s project was an easy pick and is the first one I am actually using right now: Jenv. SitePoint recently published a post about it (notice how I managed not to say we? I’m totally over it!) and it immediately delighted me.

Here’s how I used it to install Maven in two different versions, keeping the established 3.3.9 as the default but using 3.5.0 in the shell I had open:

jenv install Maven 3.3.9
# ... (when asked about making it the default, I chose "Y")
jenv install Maven 3.5.0
# ... (when asked about making it the default, I chose "n")
jenv use Maven 3.5.0

You can do the same for all kinds of Java projects, like Tomcat, Neo4j, Hadoop, or Jenkins. Isn’t that great?! If you find yourself nodding, head over to jenv.io for the installation guide — if you’re on Linux/Mac and don’t mind curling into Bash, it takes about 10 seconds. I had to follow it up with jenv repo update to make sure I had the most recent project list, though, so that will ad another few seconds.

PS: Don’t forget to subscribe or recommend! :)