Trying Out Java 9’s Modules With Gradle

I’ve touch Java 9, compiled with it, run with it, but haven’t yet done anything unique to it. I decided to see what I could do with the module system, and thought I’d see if I could migrate one of my existing project over.  I selected fluentsee because it was small, functional, and had a small number of outside dependencies.

What Resulted

I did get it to “work” with modules in play.

What Worked

  • I managed to build it as a module with Gradle
  • The module system did clarify the dependencies
  • It caught some Java reflection in play and restricted it
  • I could launch it with a simple module oriented command line

What Not So Much

  • The Gradle to deal with JDK 9 was verbose and cumbersome
  • I could not achieve the equivalent of a “fat jar” I’d had before
  • I could not get jlink to create a “deployable” application

What I Did

To get things working I used:

  • JDK 9.0.4
  • Gradle 4.4.1

And then, in my build.gradle I had to pretty much retool every Java related task.  Here’s the bulk of it:

So in addition to reworking compileJava, compileTestJava, and test, I needed to:

  • Make sure the resources got copied
  • Create a module aware jar
  • Create a task to pull everything together into a mod staging directory

With that all done I was able to:

./gradlew clean mJar module
java -p build/mods -m com.github.nwillc.fluentsee -h

To build, stage and run the project. To check out the code look at the feature/jdk9 branch of fluentsee.


Java Double Brace Initialization

I’m a fan of the JMockit framework, which if you’ve used you’ll surely be familiar with it’s “double brace” syntax. For example:

new Expectations() {{
// ...

While I’ve seen and used the double braces in JMockit, and done a bit of a double take, I’d never gotten around to figuring out what was actually going on there.

What are Those Double Braces?

Today, out of the blue, I came across a post about them, and it too just breezed by the “what” and went straight to a tip employing them.

Okay, I wasn’t going to ignore this again. So what is that double brace syntax?

It Isn’t a Thing

There is no “double brace syntax”. It’s actually a combination of two things, one fairly common, one more esoteric. A good discussion can be found here.

The concise answer is, it an anonymous class declaration, combined with an instance initializer block. A what? It’s an alternative to a constructor, and you’ve likely seen them associated only with static initialization. Who was to know there are instance initializer blocks too?

So, the double brace is a way to create and anonymous class and provide a constructor in one go. If you read the first article I referenced, they use it for adding content to collections at creation time.

Live and learn… if you bother to.

GraphQL Java 6.o

I’ve been a fan of GraphQL ever since I first tried it.  I push back against RESTful APIs to anyone that will listened (or not).  I’ve written a few post about it (GraphQL: Java Server, JavaScript Client, GraphQL: Java Schema AnnotationsGraphQL: A Java Server in Ratpack).  What I haven’t done, is stay current.  I got hooked on graphql-java at version 3.X and decided the annotations were the best way to go, and sadly the annotations development stalled and made upgrades tricky, and so I didn’t.  But it was a constant nagging itch, to upgrade, and finally I did.

This post will discuss a Ratpack server, using GraphQL-java 6.0. I should note, that as I did this work, the annotations finally release an upgrade. Doh.

GraphQL Java 6.0

I committed to upgrade. The annotations had not kept up so this meant a bit of a rewrite.  Normally I’m pretty suspicious of gratuitous annotation use.  They often mask too much of what’s really going on, and they tend to spray the information about one concern throughout your code, making it hard to locate coherent answers on a topic.  That was exactly the case here.  Leaving the annotations behind meant:

  • I had to figure out what previous magic I now had to handle on my own.
  • I had to determine just how deeply into my code they’d rooted themselves.

I tried to approach it intelligently, but in the end I went with brute force, I removed the dependency, and kept trying to build the project, ripping out references, until, while no longer working, the project built and the annotations were gone.  Then I set about fixing what I’d broken.

What Was Missing?

Basically without the annotations there were two things I needed to repair:

  • Defining the query schema
  • Wiring the queries up to the data sources

Defining Your Schema

GraphQL-java 6.0 supports a domain specific language for defining your schema known as IDL.  It’s a major win.  First, it gets your schema, which is by definition, a single concept, into one place, and makes it coherent.  Second, they didn’t go off and write “Yet Another DSL” but instead supported one that while not part of the official spec, is part of the reference implementation, and has traction in the community. Nice.

Wiring Up Your Data Sources

The best practice for this now is using the “DataFetcher” interface. The name is a bit misleading, since these aren’t just for your queries (i.e. fetching data) but also for your mutations (modifying data).  The name is weak, but the interface and it’s use is a breeze.

To the Code

I did all this work on my snippets server kata project, so for a richer example go there, but for the sake of clarity here will look at the more concise Ratpack GraphQL Server example.

The Dispatcher

This didn’t change hardly at all.  It’s still as simple as grappig a JSON map, pulling out the query and variables, and executing them:

Pretty straight forward.

Defining the Schema: IDL

So in this trivial example all I have are Company entities, defined with this bean:

And all I wanted to support was, get one, get all, save one, delete one.  So I needed to define my Company type, two queries, and two mutations. Defining this in IDL was easy:

Loading The Schema

I just tucked my schema definition into my resources folder and then:

Wiring The Data to The Schema

In GraphQL-java, the way I chose to do this is with DataFetcher implementations. So for example, to find a company, by name, from a map it would look about like:

So that’s the way to “fetch” the data, but how do you connect this to your schema? You define a “RuntimeWiring”:

And then you associate that wiring with your schema you loaded:

And Then…

Well that’s it.  You’ve:

  • Created a GraphQL dispather
  • Defined your entites
  • Defined your GraphQL schema
  • Created queries
  • Instantiated the schema, wired in the queries

Done.  Take a look at my GraphQL server in Ratpack for the complete working code.



Fluentsee: Fluentd Log Parser

I wrote previously about using fluentd to collect logs as a quick solution until the “real” solution happened.  Well, like many “temporary” solutions, it settled in and took root. I was happy with it, but got progressively more bored of coming up with elaborate command pipelines to parse the logs.


So in the best DevOps tradition, rather than solve the initial strategic problem, I came up with an another layer of paint to slap on as a tactical fix, and fluentsee was born.  Fluentsee is written in Java, and lets you filter the logs, and print out different format outputs:

$ java -jar fluentsee-1.0.jar --help
Option (* = required)          Description
---------------------          -----------
--help                         Get command line help.
* --log <String: filename>     Log file to use.
--match <String: field=regex>   Define a match for filtering output. May pass in
                                 multiple matches.
--tail                         Tail the log.
--verbose                      Print verbose format entries.

So, for example, to see all the log entries from the nginx container, with a POST you would:

$ java -jar fluentsee-1.0.jar --log /fluentd/data.log \
--match 'json.container_name=.*nginx.*' --match 'json.log=.*POST.*'

The matching uses Java regex’s. The parsing isn’t wildly efficient but keeps up generally.

Grab it on Github

There’s a functional version now on github, and you can expect enhancements, as I continue to ignore the original problem and focus on the tactical patch.


I hit on a really good article on the Law of Demeter. If you’re not familiar with it read that article, and if you do you may find my discussion with the author in the comments. The discussion was around the how rigidly you took the term Law.

Why Quibble The Word Law?

I code mostly in Java, classified as an object-oriented language, and I’ve coded in the OO paradigm in C++, Objective-C and Smalltalk too.  But I started in procedural (Pascal and C) and I’ve worked with functional (Lisp, SML), and smatterings of other languages with their styles too.  They all have their strong points. I’ve learned tactics and patterns from them all and when I’m encounter a situation where one applies, if the current tools can implement the tactic I use it.  I’m not saying anything astonishing here, modern tools are rarely purist in their approaches anymore.

The Law of Demeter is a good OO maxim, but if you’re writing code that handles serialized data, whether if be a RESTful service, or data store persistence, etc. you’ll likely be dealing with composited data (addresses, inside accounts, inside portfolios etc.).  Accessing portfolio.account.address.state violates the Law of Demeter. There are patterns to mitigate some of the issues here, like Data Transfer Objects, the Visitor Pattern, or Facade Pattern,  but depending on the situation some of these cures are worse than the problem.

In Summary

Keep the Law of Demeter in mind as you write/review your code. If it’s been rampantly ignored that certainly is a code smell.  But paradigm “laws” are for purists, and writing software is a pragmatic process… so… yeah… it’s a maxim.

Revisiting Immutables

A while back I looked into the immutables project for Java. It lets you define immutable objects in a very simple way.  Depending on your programming background you might not even see the role of an immutable object, but as more languages and patterns concern themselves with more rigorous and safer practices you may find the call for immutability in your Java.

When I looked into the project I was impressed, but at the time, the current build tools and IDEs struggled with the preprocessing requirements, and Java 7 didn’t complement it either.  All that has changed, and this project is now one I’m adding to my short list of favorites.

What You Get

I’m not going to go into a lot of detail here, there are plenty of good sources for that just a google away, but here’s the concept in brief.  The project lets you define an immutable object by simply adding annotations to an interface or abstract class, for example:

publice interface Item {
  String getName();
  Set<String> getTags();
  Optional<String> getDescription();

With that definition in place, a preprocessor will create you:

  • A immutable class that implements your interface
  • A very clean and powerful builder implementation with slick support for collections, defaults, optionals and more.

With the example above you can start using the immutable easily:

Item item = ImmutableItem.builder()
                         .name("Veggie Pizza")
                         .description("A pizza with vegetables.")

System.out.println("Order " + item.getName() + " it's a "
                       item.getDescritpion().orElse("nice choice"));

The Mechanics

The mechanics of using the project, at least with gradle, are now as simple as:

buildscript {
    dependencies {
        classpath ''

apply plugin: 'org.inferred.processors'

dependencies {
    processor 'org.immutables:value:2.4.6'

And the generated code appeared in IntelliJ seamlessly!

With Java 8

Java 8 complements the project in at least a couple of ways.  Java now has its own Optional class so you don’t need to pull in another projects for that. But what I found nicer was using default methods.  The project has long (always?) supported abstract classes as well as interfaces and so there was a way to add pure implementation code to the immutables. But interfaces provide more inheritance flexibility and now with Java 8’s default methods you can get the best if both, interfaces benefits, with accompanying method implementations!


I highly recommend giving the project a test run and incorporating immutables in your toolbox.

GraphQL: A Java Server in Ratpack

[The post is out of date, please read the update]

I previously wrote about an implementation of a GraphQL server in Java.  That post is showing age because the code is part of a kata project and constantly evolves.

A Concise Example

So, I’ve created a new concise example in GitHub that exemplifies using:

The example is just the code needed to manage a list of companies in memory. It implements basic CRUD operations but with an extensible pattern.

Grab The Code

It’s all covered in ~300 lines of code:

  1. A package with a GraphQL Schema, using a Query and a Mutation class
  2. A GraphQLHandler that dispatches POST requests to GraphQL
  3. An Application that creates the Ratpack server for the GraphQLHandler

The README covers how to run it, and there are a series sample requests included.