user-icon Lukas Oremek
11. May 2017
timer-icon 4 min

Validate architecture with Java Jigsaw

In July 2017 the version 9 of Java will be relased. A new feature of this version is Jigsaw.

Jigsaw is designed to make Java applications more modular. It introduces the concept of modules and their dependencies to each other. One benefit of a modularized application is, that modules can be optional and therfore be ommitted when linking the application. This results in much smaller size of applications which contain only the necessary modules can now be deployed to embedded plattforms with limited resources in sense of CPU, RAM and storage.

Here we don’t speak about how Jigsaw works, but about one sideeffect of Jigsaw which allows an out-of-the-box validation of software architecture.

Choose an architecture style

Every software has some kind of software architecture.

One example of an architecture style is the following simple onion architecure, which will be used as an example in this post.

The main charateristics of the onion architecture are:

  • An outer layer can not be accessed by an inner layer.
  • An outer layer can itself access several inner layers (but not necessarily each inner layer).

In our example the layer “Use Case” can access the layers “Repository Contract” and “Domain Entities” but not the layer “Controller”.

On this architecture style we will realize a car rent station application.

The implementation can look like the Java code below. The code snippets are ordered inside out, beginning with the central layer.

Domain Entities layer

Repository Contract layer

Use Case layer

Controller layer

Violation of  architecture rules

To be conform with an architectural style we need the discipline of the developer or we can use other processes like feedback based development. However, these processes are not automated. People are involved in these processes. And people make mistakes. If a developer has a bad day, he can violate this architecture like in the next example.

Here we skip the “Use Case” Layer and access the repository contract directly. The violation of the architecture rules is possible, because Java doesn’t know, that these rules exist, because there is no direct concept of layers and access control verification in Java.

Compliance of architecture rules with Jigsaw

To prevent this problem we can use the modul concept of Jigsaw. All you have to do is the correct usage of the following two keywords in the module-info.

  • export-keyword: export packages to this modules (if the is an arrow ends in this layer)
  • requires-keyword: require a module (if the is an arrow starts in this layer)

Defining each layer as a module, ensures that the rules cannot be violated. See the following code snippets for  the of our example, again starting inside out.

For the “Domain Entities” layer  we don’t need an access to other layers.  Therefore we do not have any “requires” in the module-info. We only export our own package as a module, which is needed by other modules.

For the “Repository Contract” layer we need the module “de.novatec.repositorycontract” and export the repository contracts.

The other files look simmilar to this.


Now we can’t violate our architecture rules. We can’t use any “Repository Contract” in a Controller layer. These classes are not visible in the module.

Summarized in Java 9 we can define our layers of an architecture. This has the advantage, that we can’t violate the access to another layer and we validate our architecture at compile time out-of-the-box.

What is missing in Jigsaw is a good IDE support. For example, the individual modules and thus the layers could be represented in a diagram. In this diagram you could then edit and view the modules.

Until July there is some time. Let us surprise, what Eclipse, IntelliJ etc. still make to the release of Java 9.

Comment article