Anti Pattern: Don’t use Optionals for data repositories

Java 8 Optionals

Java 8 introduced a new feature call Optionals. Optionals are an easy way to force the caller of a method to deal with a possible null return value:

If you use an Optional as the return type of your method, whoever calls the method will be reminded that it might return null. If you use Optionals, you don’t need to think about NotFoundExceptions, special return types or JavaDoc comments which state that the method might return null. An Optional says more than a thousand comments!

Optionals might just postpone the problem

But an Optional doesn’t do one thing: it doesn’t answer the question what to do if there is no method result. It just postpones the problem to the caller. This might be OK if null is a quite expected result of the method, but in most cases null means something went wrong. Don’t postpone this!

An example

Nearly every application stores data. Whenever data is stored, it will be loaded again which might go wrong as the data simply couldn’t be found. That sounds like a good use case for Optionals! Let’s see how it could look like:

Nice! If there is no Person with the given ID the repository will return an empty Optional and the caller has to deal with it. Technically, this is a nice and clean solution. But from the business perspective it isn’t. The real question is: Can it happen that we look for an ID which is not present? If yes, than an Optional is a good solution, but I would doubt that in many case.

Whenever you attempt to load data by its ID, it must be present! There are hardly any cases where you guess or search for an ID. Such IDs are like references or pointers in a programming language: they must point to something and returning an ID which points to nothing is a very bad idea. A typical situation where you load data by its ID goes like this: You provide a list of data (maybe a result of a search) and you provide a detail view on a single entry. So, you show the list in your UI and on a click on of the elements, the details of ID XYZ-123 are shown. This set of data must be there! Don’t use an optional here!

Never return null

Back in the days (which means before Java 8), there was a rule which said that you shall never return null. This rule was always a bit tricky to follow as it might lead to a lot of hidden traps. People started to return empty objects, special objects, return codes and other crazy stuff. If you did this in the past and you are using Optionals now, you definitely improved! But you should still ask you, why there might be no result and if it is OK to have no result. Not only from a technical perspective but also from the business perspective.

Optional is just a new name for null.

When to use Optionals

The actual use case for Optionals is functional programming in Java 8. If you use this, you will filter, map or reduce data and you will often come to the point where there might be the possibility that no data exists. It’s a good idea to use Optionals here, as you often write this code in a fluent style. A null pointer is really ugly to handle here. But the main difference is another: You do a search or filtering which perfectly could have no result. This is the main point for using an Optional. Don’t use an Optional, because you don’t want to deal with null (you need to do it anyway later!), use it because you have a really good reason to return null.

Best regards,
Thomas

Everytime a mock returns a mock a fairy dies

As I was reading about some Mockito features last week, I stumbled over the following tweet, which really made me laugh:

I actually found the reference to the tweet in the Mockito source code about “deep mocking” and it’s worth to think about it for a minute…

Deep mocking

Deep mocking is a really great feature from Mockito. It lets a mock return a mock, which will return a mock, which will return a mock, which will… I think you got it. Here’s an example how it works:

By passing the Mockito.RETURNS_DEEP_STUBS argument to Mockito, we tell Mockito to make a deep mock. This makes it possible to mock the result of a complete method chain in the next step.

Use deep mocking for fluent APIs

Deep mocking is very elegant way to mock fluent APIs/interfaces which are very popular right now. Fluent APIs are described by Martin Fowler (here) and are often used for builders, factories, queries or configurations.

While method-call chaining is a really bad way to write code as it’s hard to read, hard to debug and hard maintain, fluent APIs are very handy to avoid repetition in the code (e.g. to write something like builder.setId(1); builder.setName("My Object"); ...) and to lead the developer through a certain process (e.g. an object creation). Since Java’s stream API they are also part of the core Java language. You will find them in many other places, too:

  • Java 8 streams: list.stream().filter(...).map(...).sum()
  • Mockito: when(...).thenReturn(...)
  • Apache HTTP Client: Request.GET(...).connectTimeout(...).execute().returnContent()
  • Spring MockMVC: mockMvc.perform(get(...).accept(...)).andExpect(status().isOk())

Don’t use deep mocking for call chains

This brings me back to the tweet about the dying fairies on the top of this post. While the tweet doesn’t apply fluent APIs (IMHO), it definitely applies to bad written code. When every a mock returns a mock (and so on…) some encapsulation is broken. As you need to know details about the internal behavior of the mocked object (to mock it again), you are violating the Law of Demeter (the principle of least knowledge).

Fluent APIs vs. Code Chains

It’s important to know the difference between a smart and handy fluent API (which you might mock!) and a bunch of ugly code chains (which you better refactor!). Code chains break encapsulations and leak the internals of an object to the outer world. Fluent APIs on the other provide a small DSL (domain specific language) which doesn’t leek internals as it only returns the “next possible step” and guides you on your way.

References

Best regards,
Thomas

DeployMan (command line tool to deploy Docker images to AWS)

DeployMan

2014-07-29 11_34_11-Java EE - Eclipse

Yesterday, I published a tool called DeployMan on GitHub. DeployMan is a command line tool to deploy Docker images to AWS and was the software prototype for my master thesis. I wrote my thesis at Informatica in Stuttgart-Weilimdorf, so first of all, I want to say thank you to Thomas Kasemir for the opportunity to put this online!

Disclaimer

At the time I am writing this post, DeployMan is a pure prototype. It was created for academic research and as a demo for my thesis. It is not ready ready for production. If you need a solid tool to deploy Docker images (to AWS), have a look at Puppet, CloudFormation (for AWS), Terraform, Vagrant, fig (for Docker) or any other orchestration tool that came up in the last couple of years.

What DeployMan does

DeployMan can create new AWS EC2 instances and deploy a predefined stack of Docker images on it. To do so, DeployMan takes a configuration file called a formation. A formation specifies how the EC2 machine should look like and which Docker images (and which configurations) should be deployed. Docker images can either be deployed from a Docker registry (the public one or a private) or a tarballs from a S3 storage. Together with each image, a configuration folder will pulled from a S3 storage and mounted to the running container.

Here is an example of a formation which deploys a Nginx server with a static HTML page:

Interfaces

DeployMan provides a command line interface to start instances and do some basic monitoring of the deployment process. Here is a screenshot which shows some formations (which can be started) and the output of a started Logstash server:

Run_Logstash_Server

To keep track of the deployment process in a more pleasant way, DeployMan has a web interface. The web interface shows details to machines, such as the deployed images and which containers are running. Here is how a Logstash server would look like:

Machine_Details

The project

GitHub-Mark

You can find the project on GitHub at https://github.com/tuhrig/DeployMan. I wrote a detailed README.md which explains how to build and use DeployMan. To test DeployMan, you need an AWS account (there are also free accounts).

The project is made with Java 8, Maven, the AWS Java API, the Docker Java API and a lot of small stuff like Apache Commons. The web interface is based on Spark (for the server), Google’s AngularJS and Twitter’s Bootstrap CSS.

Best regards,
Thomas

Development speed, the Docker remote API and a pattern of frustration

One of the challenges Docker is facing right now, is its own development speed. Since its initial release in January 2013, there have been over 7.000 commits (in one year!) by more than 400 contributors. There are more than 1.800 forks on GitHub and Dockers brings up approximately one new release per month. Docker is in a super fast development right now and this is really great to see!

However, this very high development speed leaves a lot of third-party tools behind. If you develop a tool for Docker, you have to keep a very high pace. If not, your tool is outdated within a month.

Docker remote API client libraries

A good example how this development speed affects projects, are the remote API libraries for Docker. Docker offers a JSON API to access Docker in a programmatic way. It enables you for example to list all running containers and stop a specific one. All via JSON and HTTP requests.

To use this JSON API in a convenient way, people created bindings for their favorite programming language. As you can see below, there exist bindings for JavaScript, Ruby, Java and many more. I used some of them on my own and I am really thankful for the great work their developers have done!

But many of those libraries are outdated at the time I am writing this. To be exact: all of them are outdated! The current remote API version of Docker is v1.11 (see here for more) which none of the remote API libraries supports right now. Many of them don’t even support v1.10 or v1.9.

Here is the list of remote API tools as you find it at http://docs.docker.io/reference/api/remote_api_client_libraries/.

Language Name Remote API
Python docker-py v1.9
Ruby docker-api v1.10
JavaScript (NodeJS) dockerode v1.10
JavaScript (NodeJS) ocker.io v1.7
JavaScript (Angular) WebUI dockerui v1.8
Java docker-java v1.8
Erlang erldocker v1.4
Go dockerclient v1.10
PHP Docker-PHP v1.9
Scala reactive-docker v1.10

How to deal with rapidly evolving APIs

How to deal with rapidly evolving APIs is a difficult question and IMHO Docker made the right decision. By solely providing a JSON API Docker chose a modern and universal technique. A JSON API can be used in any language or even in a web browser. JSON (together with a RESTful API) is the state-of-the-art technique to interact with services. Docker even leaves the possibility to fall back to an old API version by adding an version identifier to the request. Well done.

But the decision to stay “universal” (by solely providing a JSON API) also means to don’t get specific. Getting specific (which means to use Docker in a certain programming language) is left to the developers of third party tools. These tools are also evolving rapidly right now, no matter if those are remote API bindings, deployment tools (like Deis.io), or hosting solutions (like CoreOS). This enriches the Docker ecosystem and makes the project even more interesting.

Bad third party tools will fall back on you

The problem is, even if Docker made a good job (which they did!), outdated or poorly implemented third party tools will fall back on Docker, too. If you use a third party library (which you maybe found via the official website) and it works fine, you will be happy with Docker and the third party library. But if the library doesn’t work next month because you updated Docker and the library doesn’t take care of the API version, you will be frustrated about the tool and about Docker.

Pattern of frustration

This pattern of frustration occurs a lot in software development. Bad libraries cause frustrations about the tool itself. Let’s take Java as an example. A lot of people complain about Java that it is verbose, uses class-explosions as a pattern and makes things much more complicated as they should be. The famous AbstractSingletonProxyFactoryBean class of the Spring framework is just such an example (see +Paul Lewis). Another example is reading a file in Java which was an awful pain:

And even the new NIO API which came with Java 7 is not as easy as it could be:

You need to put a String into a Path to pass it into static method which output you need to put into a String again. Great idea! But what about something like this:

However, it is not the fault of Java, but of a poorly implemented third party tool. If you need to put a File into a FileReader which you need to put into a BufferedReader to be able to read a file line by line into a StringBuilder you use a terrible I/O library! But anyway, you will be frustrated about Java and how verbose it is (and maybe also about the API itself).

This pattern applies to many other things: You are angry about your smartphone, because of a poorly coded app. You are angry about Eclipse because it crashes with a newly installed plugin. And so on…

I hope this pattern of frustration will not apply to Docker and the community will develop a stable ecosystem of tools to provide a solid basis for development and deployment with Docker. A tool like Dockers lives trough its ecosystem. If the tools are buggy or outdated, people will be frustrated about Docker – and that would be a shame, because Docker is really great!

Best regards,
Thomas

Java 8 for Eclipse Kepler via the Eclipse Marketplace

Eclipse Foundation Announces Java 8 Support! One day after my post about Java 8 in Eclipse Kepler (4.3) and Eclipse Luna (4.4), the Eclipse Foundation announced official support for Java 8 in Eclipse Kepler. Here is there blog post straight outta Ottawa, Canada:

http://eclipse.org/org/press-release/20140402_eclipse_foundation_announces_java8_support.php

You can now install Java 8 support to Eclipse Kepler (4.3) via the Eclipse Marketplace:

2014-04-0Eclipse

A little bit late (!), but finally the easiest way to use Java 8 in Eclipse.

Best regards,
Thomas

Java 8 in Eclipse (Kepler and Luna)

Java 8 is officially available since a couple of days. It was released on March 18th this year. Yeah! But – Eclipse, the biggest and most popular Java IDE is a little bit behind the schedule (at least IMHO). There is no official Eclipse version for Java 8 right now!

But there are two other thing: an up-to-date nightly build of the new Eclipse version Luna which will be released with Java 8 support and a patch for the current Eclipse version Kepler! Since it is sometimes (= always) hard to find the correct Eclipse version on eclipse dot org or anything useful at all, here is how to do it.

Java 8 in Eclipse Juno (4.2)

If you still use Eclipse Juno (4.2), you use an old version of Eclipse without Java 8 support and I strongly recommend to use a new version (as described below). If you cannot do that (or don’t want to do that) here is an old tutorial from me how to setup Java 8 in Eclipse Juno: http://tuhrig.de/java-8-in-eclipse-juno.

Java 8 in Eclipse Kepler (4.3)

2014-03-31 12_16_15-Program Manager

Kepler (4.3) is the current version of Eclipse. You can download it from http://www.eclipse.org/downloads. After you downloaded it, it will not have Java 8 support right out of the box! To add it, you have to install a feature patch:

  1. Download and install Java 8 (e.g. from Oracle JRE/JDK or OpenJDK)
  2. Add it to Eclipse:
    2014-03-31 12_25_37-Java - Java8Project_src_Test.java - Eclipse
  3. Install the feature patch via Help > Install New Software...:

    2014-03-31 12_04_14-Java - test_src_test_Hello.java - Eclipse

You have to restart Eclipse during the installation and accept a license and click several next-buttons. But after you installed the feature patch, you have Java 8 support in Eclipse Kepler (4.3). If you have problems with the installation process, download a new Eclipse Kepler version.

2014-03-31 12_34_14-

Java 8 in Eclipse Luna (4.4)

2014-03-31 16_18_56-C__Users_tuhrig_AppData_Local_Temp_7zOADE2.tmp_repositories • - Sublime Text 2 (

Luna (4.4) is the upcoming version of Eclipse. It will be released this summer and it will contain Java 8 support. But you can already download some nightly builds of it which contains Java 8 support.

You can download Eclipse Luna here. Just make sure you download the correct build version, since not all builds have Java 8 support already! When you download the correct version, you can just run Eclipse and use the new Java 8 features (you also need to install Java 8, e.g. from Oracle JRE/JDK or OpenJDK).

2014-03-31 12_38_38-Eclipse Project Downloads

By the way, some nightly builds still contain test errors. This is due to the fact that Eclipse Luna is still in development. But to play around with Java 8 or for a small project it should already be good enough.

2014-04-01 07_42_46-Eclipse Project

A simple Java 8 example

To test your Eclipse IDE, here is a very simple Java 8 example:

Troubleshooting

If you have problems with Java 8 in Eclipse check your project settings. If your compliance level is not set to 1.8, you cannot use Java 8. And if you don’t even have the compliance level 1.8 then your Eclipse somehow doesn’t support Java 8 and something went wrong. In this case, get yourself a new Kepler version and install the feature patch or download an appropriate Luna build as described above.

2014-03-31 12_12_56-Java - test_src_test_Hello.java - Eclipse SDK

Resources

Best regards,
Thomas

What static methods for interfaces tell you about the Java community

Recently I was putting together some code for an OSGi plugin at work. I created an interface to add listeners to an extension point. The code looked something like this:

The idea was simple: At some points in my application I would call all registered listeners, pass them an object and let them do whatever they are supposed to do. The only problem was, that the code to call these listeners is pretty cumbersome:

FML! In reality it looks even more cumbersome with some exception-handling and logging.

So the first thing I did was a utility class to put that code to and never see it again. But utility classes are not a very good practice at all. So I thought about a suitable place for my code. Some kind of a factory? Or some invoker object? But isn’t that just another name for a utility class? Or… why not put it in the interface itself? So the method to deal with the interface would stay in the interface itself.

A minute and a compile time error later it came back to my mind: interface can’t have static methods in Java! (I will come back to this later…)

But why can’t interfaces have static methods?

The question seems legit to me. Classes as well as abstract classes can have static methods and interfaces can have static classes and static fields. But no static methods. Why?

Ask Google!

I did what I’m always doing when I have a question, I asked Google. Five minutes later I had a bunch of different answers:

It’s not possible!

Everything is possible. Especially in Computer Science.

It doesn’t make sense!

I can give you 10 situations in a minute where it makes sense. Let’s start with the one above.

Your desing is wrong!

Is it? Would a new class with just a single method make it better?

You know nothing about OO!

So if I put a static method in an abstract class it’s called a pattern (the Factory Pattern of the GoF) and if I want to do something similar in an interface, I have no clue what I’m doing? Languages like Ruby which are OO from the ground up (not like Java) have similar concepts.

The truth?

As always in software development there’s no certainty. There are a thousand ways to implement the case a both, every with its own pros and cons. One is beautiful OO, one reads nice, another one is easy to test and one is just as sophisticated as it could be. But the best explanation I found is this:

It’s just a design decision of the Java makers.

It is! Like everything that is in the language or not. And as many things that were discussed over the years, it will finally come with the next Java release. Java 8 will have static methods for interfaces. It will also have default implementations for interfaces and Lambda-expressions. OO? Nope, just good to write code.

The community

I looked in a dozen different forums and Q&A sites for a proper explanation. But I didn’t find much good answers. It is just a decision of some guys made a couple of years ago. And right now, it seems that they are doing the very reverse – put static methods for interface in Java 8.

But what really shock me is the way it is discussed in the community. A lot of people are almost religious about it. They don’t have a clue what it’s about, so it must be huge design mistake, not OO or even not possible.

I think strong opinions are never. Not in politics, not in art and especially not in software development. Maybe that’s why Java moves as fast as it does?

The hack

Btw, there is a very easy hack to add static methods to an interface in Java 7. Interfaces can have static classes which can have static methods. It’s not the nicest thing ever, but at least it lets you put your “utility class” together with the interface.

Best regards,
Thomas

Java 8 in Eclipse (Juno)


Note: Here is an up-to-date tutorial for the new Eclipse versions Kepler and Luna: http://tuhrig.de/java-8-in-eclipse-kepler-and-luna


Since last July the new Java 7 is generally available. However, even the newer Java 8 is already available as an Early Access Preview. It can be download as part of the OpenJDK including lambda-support. To use it with Eclipse, some additional steps are required. Here’s how it goes:

  1. Download the JDK from http://jdk8.java.net/lambda and install it.
  2. Create a new Java project in Eclipse.
  3. Change some project settings in Eclipse in order to use the new javac compiler of Java 8:
    1. Click right on your project and select Properties.
    2. Select Builders on the left side and uncheck the default Java Builder.
    3. Click on New and select Program as the type of the new builder.
    4. Open javac from the JDK 8 on your disk (it’s in the folder bin).
    5. Configure the new builder by providing some arguments:
    6. Select the tab Build Options and check the During auto builds box, to let the builder run automatically.
  4. Done! Now you can write and execute Java 8 code!

The main feature of Java 8 is the ability to write lambdas and use a functional-like programming style. This can be very useful, especially in GUI-programming. It can reduce the amount of code, because anonymous classes that only implements a listener-interface are avoided. Here’s a very simple example:

The code creates a common JFrame with two buttons. To each button an action-listener is added. But instead of implementing an anonymous class, a method reference is passed in the first case and a lambda in the second case. This reduces the amount of code compared with the old solution that looked like this:

However, the Java compiler will create exactly such a thing of the lambda expression or function reference. Therefore, the passed method must fulfill the interface described by ActionListener. Also, we can only use lambdas instead of interfaces that only describe one single method. Such interfaces are called functional interfaces.

Since Eclipse Juno is made for Java 7 it will not recognize the new lambda syntax. Hence, the editor will mark parts of the code as red errors. But it’s still possible to compile and to execute the code using the new javac compiler form Java 8.

Best regards,
Thomas Uhrig