Nim's Cynical Pleasantries Code, swords and a dirty mind!


JAX-RS Client Filters

Life goes on with JAX-RS/Jersey. I wasted a couple of moments figuring out how to add custom headers to a Jersey generated JAX-RS client. Might as well write it down in the hope of saving someone a couple of minutes.

For starters, you'll need a Client Filter that does the actual heavy(ish) lifting.

 * Add the X-GARBAGE header to all requests.
public class GarbageFilter implements ClientRequestFilter {
	public void filter(final ClientRequestContext requestContext) throws IOException {
		requestContext.getHeaders().add("X-GARBAGE", "This is added to all requests");

And then you'll have to register the filter with the Client(Config).

// import org.glassfish.jersey.client.ClientConfig;
final ClientConfig clientConfig = new ClientConfig();
clientConfig.register(new GarbageFilter()); // Yes, you could use JDK8 magic :-)
final Client client = ClientBuilder.newClient(clientConfig);

And that's all. Every request you launch using the generated client will now contain your X-GARBAGE header.

Tagged as: , No Comments

JAX-RS Client File Upload

Another hiccup in using the wadl2java client generated from a (Jersey) JAX-RS app. This time, it concerns multipart/form-data.

The method:

	public JsonFoo create(@FormDataParam("file") InputStream data, 
		@FormDataParam("file") FormDataContentDisposition fileDetail, 
		@FormDataParam("file") FormDataBodyPart bodyPart) {
			// Implementation foo bar baz

The WADL exposes something that looks like this.

<method id="create" name="POST">
		<representation mediaType="multipart/form-data"/>
	<!-- Response omitted for the sake of brevity -->

And the generated client has a method to go along with it. Unfortunately, it gives you no hints whatsoever as to how to actually provide a file/data.

// Long class names shortened
public static Create create(Client client, URI baseURI) {
	return new Create(client, baseURI);
// The Create object contains this little gem
public<T >T postMultipartFormDataAsJson(Object input, GenericType<T> returnType);

That's wonderful. Unfortunately, if you pass in a, nothing happens. The client barfs.

Many DuckDuckGo-searches, StackOverflow hunts and headscratchings later, I came up with a working solution:

// import import;
// import;
File file = new File(); // Your file!
FormDataMultiPart form = new FormDataMultiPart();
form.field("filename", file.getName());
form.bodyPart(new FileDataBodyPart("file", upload, new MediaType("image", "jpeg")));
Api.create(client, uri).postMultipartFormDataAsJson(form, new GenericType<CreateResponse>() {});

But wait! That won't cut it. You also need to tell your Client that you want to use the Multipart Feature. Makes sense. If you don't, you'll end up with this exception.

org.glassfish.jersey.message.internal.MessageBodyProviderNotFoundException: MessageBodyWriter not found for media type=multipart/form-data, type=class, genericType=class
// import org.glassfish.jersey.client.ClientConfig;
// import;
final ClientConfig clientConfig = new ClientConfig();

And there you have it. File upload with JAX-RS and a wadl2java generated client.

Tagged as: , No Comments

JAX-RS vs Collections vs JSON Arrays

The Problem

Looks like I've managed to get myself into a pickle. I have a (Jersey) JAX-RS app, which automagically publishes a WADL. If I then generate a Client (using wadl2java), I end up with generated code that doesn't work.

	public List<Foo> get() {
		return myList;

Foo is a simple POJO with an @XmlRootElement annotation. The resulting JSON is perfectly fine: I get a JSON Array with a bunch of Foo objects. Perfect!

The generated WADL is a different matter:

    <method id="get" name="GET">
            <!-- foo is a reference to an XSD Complex Type ... but where's my list? -->
            <ns2:representation element="foo" mediaType="application/json"/>

For some reason, the WADL generator is smart enough to realise that we're dealing with Foo instances. But it's too stupid to realise that we're dealing with more than one.

If you then generate a Client using wadl2java, you'll end up with something like this:

    public Foo getAsFoo() {
        return response.readEntity(Foo.class);

Well that's not going to work, is it? Trying to read a single Foo when you've got an array of them. And indeed ... you get a wonderful exception.

Internal Exception: java.lang.ClassCastException: Foo cannot be cast to java.util.Collection

This seems to be a fundamental XML vs JSON problem. After all there is no such thing as an "XML Array". Either you have one element, or you have multiple elements nested under a common root.

I could solve this by not relying on a plain JSON Array and encapsulating the result.

// Not this:
// But this:

But then that's ugly. And instead of using a native Java collection I'll have to create a useless intermediary object. And it would break compatibility with current API clients.

The Solution

Whelp ... I haven't found one yet. To be continued, I hope. But I did manage to find a workaround, thanks to Adam Bien's blog.

The incorrectly generated getAsFoo() method doesn't work. But we can use getAsJson() instead -- which doesn't necessarily have to return a JSON string.

    List<Foo> foos = client.getFoo().getAsJson(
        new GenericType<List<Foo>>() {

GenericType is a dirty JAX-RS hack in my opinion, but it works. It's a shame that I have to rely on getAsJson(), though. It would've been much cleaner to use the getAsFoo() method directly.

Tagged as: , No Comments

Endless Locale Bugs

This isn't the first time I've ranted about Locale related issues. It probaly won't be the last, either.

Currently my biggest gripe is with convenience methods in Java which rely on platform defaults, and are thus platform-specific. For instance, the venerable System.out.println() will terminate your line with whatever your platform thinks a line ending should be. Printing dates or numbers will try to use your platform Locale. Writing a string to a file will default to platform encoding.

Some of these defaults can be controlled at run time, others require JVM startup options. This is all horribly wrong. This results in all kinds of unexpected behaviour. It's error-prone. None of this should be allowed to happen. Any method that assumes platform-specific magic should be deprecated. Which is exactly what I'll do, as soon as I can figure out how to write a Sonar plugin to detect all this nonsense.


Getting started with JAX-RS & Gradle

Managed to waste an hour of my life today, trying to set up a JAX-RS + Gradle project. Gradle wasn't really the problem, nor was JAX-RS, but putting it all together in a way that works took longer than expected.

So without further ado, I present to you a simple quickstart project you can use to kickstart JAX-RS + Gradle projects.

The Gradle build file is pretty minimalistic. There's no need for web.xml. And I've included an example resource.


description = 'JAX-RS Quickstart'
group = ''
version = '1.0-SNAPSHOT'
apply plugin: 'java'
apply plugin: 'eclipse'
sourceCompatibility = 1.8
repositories {
buildscript {
        repositories {
        dependencies {
                // Embedded Jetty 9 Gradle Plugin
                classpath (group: 'com.sahlbach.gradle', name: 'gradle-jetty-eclipse-plugin', version: '1.9.+')
apply plugin: 'jettyEclipse'
apply plugin: 'war'
dependencies {
        // JAX-RS 2.0(.1)
        compile ''
        // Jersey 2.15
        compile 'org.glassfish.jersey.containers:jersey-container-servlet:2.15'
        // Servlet 3
        compile 'javax.servlet:javax.servlet-api:3.1.0'

Extra quick quickstart:

git clone
cd jax-rs-quickstart
gradle jettyEclipseRun
Tagged as: , 1 Comment

I guess I should be honoured?

Someone seems to have named their programming language after me. Thanks for the compliment πŸ˜‰

Filed under: Uncategorized 1 Comment

More Open Source donations

The end of the year is upon us, and the kind folks over at GnuPG (gpg) are asking for donations. I pitched in along with many others, and I would encourage anyone who values online privacy to do the same. GPG is a critical part of open source development, extremely useful for signing releases or securing communications.

If you have a little cash to spare, consider making a donation to a FOSS project you like or use. A little goes a long way. Thanks!

Tagged as: , No Comments

Gradle gotcha: duplicate project names

Assume the following project structure:

β”‚Β Β  β”œβ”€β”€ Foo
β”‚Β Β  β”‚Β Β  β”œβ”€β”€ build.gradle
β”‚   β”œβ”€β”€ Bar
β”‚   β”‚   β”œβ”€β”€ build.gradle
β”‚   β”œβ”€β”€ Foo
β”‚   β”‚   β”œβ”€β”€ build.gradle
β”‚   β”œβ”€β”€ Quf
β”‚   β”‚   β”œβ”€β”€ build.gradle

I don't think this is a terribly unreasonable structure: we have a product with a bunch of features, and each feature is split into a couple of modules. This works just fine in gradle. As long as FeatureB/Foo doesn't have a dependency on FeatureA/Foo. Gradle doesn't seem to be terribly fond of multi-module projects. At least not when you have a deeper, nested structure.

As soon as FeatureB/Foo has a dependency on FeatureA/Foo, gradle goes belly up. It won't tell you, though. It'll just quietly carry on. It won't resolve the dependency, and you'll end up with compile errors.


dependencies {
	compile project(':FeatureA:Foo')

The reason is actually quite simple. Gradle uses the directory name as the project name. Instead of looking at the whole path in the tree, which would be a lot more sensible, it just looks at the last leaf in the tree. So we have two projects named Foo, and gradle chokes. Not giving an error/warning strikes me as a bug, though, but still. Not terribly unreasonable.

Thankfully, there's a fix. It involves renaming your projects via settings.gradle in the root project:


// List our projects/subprojects
include ':FeatureA:Foo'
include ':FeatureA:Bar'
include ':FeatureB:Foo'
include ':FeatureB:Quf'
// Rename each child project to its path: Foo becomes FeatureA-Foo or FeatureB-Foo, depending on the Foo.
rootProject.children.each { p ->
        p.children.each { module ->
       = + '-' +

Now you can add a project dependency and things will Just Work™:

dependencies {
	compile project(':FeatureA:FeatureA-Foo')

All fixed. Much better.

Tagged as: No Comments

Dear PHP Developers, please stop using the closing tag ?>

Dear PHP Developers, please stop using ?> at the end of your scripts. There's no need for it, it's ugly, and it's a nightmare when you've got whitespace hiding behind the tag.

So stop, please. Just, stop.

Tagged as: , No Comments


My Thinkpad x230 gave me a bit of a scare recently. The display died out of the blue, and Lenovo's support was an absolute nightmare. In spite of next business day on site warranty, it took them nearly two weeks to actually fix the bloody thing. The first time the tech showed up, he replaced the broken panel with another broken panel. Not too useful, that.

While I was in limbo, unsure if it would ever get fixed under warranty, and wondering how much it would cost me to have it fixed, I spent some time researching alternatives.

Sadly, I found none. It seems like literally no one makes laptops for people who use use them anymore. There's loads of consumer-grade crap out there, but nothing useful. Especially in the 12.5" range.

There are a couple of recurring failures.

Keyboard & Mouse


The Thinkpad x240 -- "new and improved" -- comes with a trackpad that takes up more space than the fucking keyboard. The top buttons (used in conjunction with the nipple) are part of the trackpad. Apparently if you disable the trackpad, you're out of luck and out of buttons. Great. Turning off the trackpad, of course, is mandatory, given that the thing is so fucking huge that my thumbs constantly touch it inadvertently. Especially annoying when focus follows pointer.

The picture doesn't do it justice, but another problem with the x240 is that the function keys got smaller and are now closer to the number row than before. Makes for an overall less enjoyable experience.



These ASUS & Dell pieces of shite both seem to be missing a bunch of keys (page up, page down, home, insert, end, ...) and seem to have completely flat keys. Apparently there's a market for people who don't type.

Mechanical failures waiting to happen



Whoever designed these amazing ultra portable laptops seems to have forgotten that people will be moving around with them. Those display look like they'll snap in half the first time you bump into anything. And seriously, who the fuck needs a detachable display? Who buys this? What do they do for a living? Not software engineers, that's for sure.


Apparently everybody and their grandmother wants a touchscreen. I can't for the life of my imagine why. Having to use a mouse (due to terrible window management and non-keyboard-friendly websites) is already a waste of time. Having to touch my screen (and leaving greasy fingerprints everywhere) is even worse. Fuck that shit.

So ...

Laptops that don't suffer from any of the above flaws are few and far between, and usually have a CPU that's slower than my phone's, or less memory than my toaster. Anything that ships with an AMD CPU isn't even worthy of being a coaster, either. Makes you wonder how they're still relevant.

Apparently there are literally no laptops on the market for software engineers. There's all kinds of crap designed around this Windows 8 insanity with its useless tablet-like interface. I'm sure these machines are perfectly fine for consuming information like some kind of brain dead zombie, but there's no universe in which these machines are useful for creating or getting any work done.

Needless to say, I'm quite happy that Lenovo did repair my x230 in the end. Hopefully it'll outlive its warranty. With a bit of luck, the x250 or x260 won't suck quite as much...

Filed under: Uncategorized 2 Comments