Automatically generating your API from a swagger file using gradle

Normally when using swagger, you generate a swagger.yaml file for your API. But what if you already have a swagger.yaml file and you want to generate the API interface and models, like you would also do with a webservice using a WSDL file? To achieve this, swagger has a great tool: swagger-codegen. The tool has a CLI and a maven plugin, but no gradle plugin. So how do we use it with gradle?

Here is a list of things we need to do to get it to work:

  • Create a gradle task that generates the API interface every time we build (which should be generated to src/generated/java to keep everything separated)
  • Make sure ‘gradle clean’ also cleans the generated files
  • Support gradle incremental builds
  • Making sure it compiles: the generated classes should be available in src/main/java, and execute the generate task before build/compile
  • BONUS: IntelliJ should generate the files automatically when you import the project or sync the project.

A big thanks to my colleague Willem Cheizoo from JDriven for helping me create this list and pointing me in the right direction.

Creating a generate task

To be able to use the codegen in our gradle task, we need to add the dependency to the buildscript in our build.gradle file.

Continue Reading

Forcing HTTPS with an .htaccess file on Heroku

The usual way

Normally, forcing HTTPS with an .htaccess file is pretty straightforward, and not too difficult. You simply add the following to the top of your .htaccess file:

You have a RewriteCond that checks whether HTTPS is on or off, and after that you create a RewriteRule that redirects the user to the same host/URI, but with HTTPS instead of HTTP. The L flag prevents any other rule in the .htaccess file from being applied, and the R flag is a redirect (the 301 status code is for SEO optimization).

See this for documentation on rewrite module for Apache server.

Why is it not working on Heroku?

So when you try this on an application hosted on Heroku (I’m using a Cedar stack), this won’t work because there will be a infinite redirect loop.

Continue Reading

Promise me you won’t use Promise.race

Before we start, if you’re not sure what JavaScript Promises are, read this post. It’s a really great introduction for Promises. Furthermore, the code examples in this post uses Arrow functions, if you are unfamiliar with them, check out this link for an explanation.


My colleague, Erik Timmers, and I often have discussions about programming and related technologies. This blog post is the result of one of those discussions. We discovered that the function Promise.race didn’t exactly do what we expected. So we tested it, figured out how it worked, found out what we thought was wrong, and finally created a version of the Promise.race function that does what we expected. After that we went a little bit further…and added some functionality to the function. Please note that this code shouldn’t be used in production, or at the very least, it should be tested a bit more. We did it “because we could”, but also because we wanted to understand the functionality. If you would like to view, extend, learn from the actual code, the source code is also available on GitHub.

So what’s wrong with Promise.race?

So you’re working on a JavaScript application, and your IntelliJ (because why would you use any other IDE?) autocomplete pops up with the function ‘race’ when you write ‘Promise.’. So without looking at the documentation, what would you expect Promise.race to do?
My first though was, that you can probably pass a few promises to this function and it returns the value of the first promise that resolved. Makes sense right?

Continue Reading

Modify Java 8 final behaviour with Annotations

How I started this project

Some time ago I went to a Meetup session Death To Null by Ties van de Ven from JDriven. During the presentation it became clear that it wasnt so much about null checks and NullPointerExceptions but more about Immutability and how it can help keep your software free of bugs and NullPointerExceptions. One of the statements that got me thinking was (something along the lines of): Java chose the wrong default. Instead of making everything explicitly final when we want an immutable variable, everything should be implicitly final unless the developer makes it explicitly mutable.
Not knowing that much about the implementation of annotations I thought it would be fun to try to write an annotation which would do exactly that. The first bump I encountered is that annotations cannot modify the programmers source code, or the classes generated from this source code; they can generate new sources or validate code. This quickly turned my attention to project Lombok which does that already. If you use project Lombok for the generation of getters and setters these never show up in your source code. How can your IDE still hint at the existence of the getters and setters?

It turns out that the Java compiler is an iterative process. First the compiler parses your source code into something which is called an AST or Abstract Syntax Tree. Then annotation processors are run to generate extra sources or do some extra validation based on your annotations. Compilation errors, such as invalid classes or invalid method calls, are done in phase 3. If, however, an annotation processor generates new sources, the compiler repeats step 1 and 2 before going to step 3.

Project Lombok, and my proof of concept, will use a bit of a hack. Instead of generating new sources with the annotation processor, it modifies the generated AST. This will allow the processor to change the code without touching the source code or the byte code.

A more detailed explanation can be found here. It is a bit dated, but informative.

Building a PoC

For my proof of concept Ive decided to create a new maven project. It will have two sub projects, one of them contains the annotation itself and the processor which will process it, the other one contains a test class which uses the annotation.

Continue Reading