Nicolai Parlog, Mar 17

How Project Amber Will Revolutionize Java

Project Amber is the roof under which several productivity-oriented Java language JEPs like more type inference and pattern matching are developed.
Pierre-Yves Saumont, Mar 15

What Is Referential Transparency?

Referential transparency is a tool to help programmers reason about their programs and make them safer, and easier to test and to maintain.
Pierre-Yves Saumont, Mar 13

Types Are Mightier than Tests

Functional programming can dramatically reduce the need for testing by using types to reduce the number of possible implementation choices.
Simon Ritter, Mar 10

Is An Agile Java Standard Possible?

In recent years Java's evolution came to more heavily rely on JEPs. Simon Ritter explains how that can make Java's development more agile.
Indrek Ots, Mar 08

Java's If Statement in Five Minutes

If statements are used to conditionally run blocks of code. They're an essential tool for controlling the flow of a program
Arnaud Roger, Mar 06

Deep Dive into Java 9's Stack-Walking API

Introduction to Java 9's stack-walking API. Learn how to use the StackWalker, its options, and its performance characteristics.
Nicolai Parlog, Mar 03

Git Better! Learn Aliases, Settings, Tools, Background

Chances are you're using Git - a lot. Here's how to use it better! Aliases, settings, tools, and a little background about usability and documentation.
Nicolai Parlog, Mar 01

Understanding Java's Reflection API in Five Minutes

Java's reflection API allows the inspection and invocation of types, methods, fields, annotations, etc. without creating compile time dependencies.
Tao Wen, Feb 27

PHP-Style JSON Parsing in Java with Jsoniter

Jsoniter, a Java library for parsing JSON similar to PHP's json_decode, features a weakly typed `Any`, lazy parsing, and great performance.
Ivan Mushketyk, Feb 22

Java's Synchronized Keyword in Three Minutes

The synchronized keyword is a common building block in concurrent Java applications. Learn how to use it to avoid race conditions.
Pierre-Yves Saumont, Feb 20

Lazy Computations in Java with a Lazy Type

Java is known as a mostly strict language. It's useful, however, to implement a 'Lazy' type for lazy initialization, deferred computations, etc.
Nicolai Parlog, Feb 17

How Conferences Feed the Hype Cycle

Lots of great conferences have lots of great speakers. But does the lack of everyday developers speaking about their experiences feed the hype cycle?
Ivan Mushketyk, Feb 15

The Dangers of Race Conditions in Five Minutes

A race condition occurs when multiple threads mutate shared state such that the outcome depends on how exactly the threads' operations interleave.
Ivan Mushketyk, Feb 13

Beyond POJOs - Ten More Ways to Reduce Boilerplate with Lombok

How to use Lombok to reduce Java boilerplate in logging, null checks, variable definitions, concurrent code, exception handling, laziness, and more.
Galo Navarro, Feb 10

How Does the Default hashCode() Work?

Java's Object class has a hashCode() implementation. But what does it do? Where do the values, often mistakenly assumed to be memory addresses, come from?
Ivan Mushketyk, Feb 08

Java's Thread Class in Five Minutes

Threads are Java's basic abstraction for running code in parallel. Learn how to use the Thread class to launch, finish, and wait for threads.
Pierre-Yves Saumont, Feb 06

In Praise of Laziness

Java is known as a strict language regarding references and method arguments. It's however possible (and very useful) to implement laziness in types.
Nicolai Parlog, Feb 02

Java Module System Hands-On Guide

In this post we'll take an existing demo application and modularize it with Java 9. If you want to follow along, head over to GitHub, where all of the code can be found. The setup instructions are important to get the scripts running with Java 9. For brevity, I removed the prefix org.codefx.demo from all package, module, and folder names in this article.

The Application Before Jigsaw

Even though I do my best to ignore the whole Christmas kerfuffle, it seemed prudent to have the demo uphold the spirit of the season. So it models an advent calendar:
  • There is a calendar, which has 24 calendar sheets.
  • Each sheet knows its day of the month and contains a surprise.
  • The death march towards Christmas is symbolized by printing the sheets (and thus the surprises) to the console.
Of course the calendar needs to be created first. It can do that by itself but it needs a way to create surprises. To this end it gets handed a list of surprise factories. This is what the main method looks like:
public static void main(String[] args) {
	List<SurpriseFactory> surpriseFactories = Arrays.asList(
			new ChocolateFactory(),
			new QuoteFactory()
	Calendar calendar =
The initial state of the project is by no means the best of what is possible before Jigsaw. Quite the contrary, it is a simplistic starting point. It consists of a single module (in the abstract sense, not the Jigsaw interpretation) that contains all required types:
  • "Surprise API" - Surprise and SurpriseFactory (both are interfaces)
  • "Calendar API" - Calendar and CalendarSheet to create the calendar
  • Surprises - a couple of Surprise and SurpriseFactory implementations
  • Main - to wire up and run the whole thing.
Compiling and running is straight forward (commands for Java 8):
# compile
javac -d classes/advent ${source files}
# package
jar -cfm jars/advent.jar ${manifest and compiled class files}
# run
java -jar jars/advent.jar

Entering Jigsaw Land

The next step is small but important. It changes nothing about the code or its organization but moves it into a Jigsaw module.


So what's a module? To quote the highly recommended State of the Module System:
A module is a named, self-describing collection of code and data. Its code is organized as a set of packages containing types, i.e., Java classes and interfaces; its data includes resources and other kinds of static information. To control how its code refers to types in other modules, a module declares which other modules it requires in order to be compiled and run. To control how code in other modules refers to types in its packages, a module declares which of those packages it exports.
(The last paragraph is actually from an old version of the document but I like how it summarizes dependencies and exports.) So compared to a JAR a module has a name that is recognized by the JVM, declares which other modules it depends on and defines which packages are part of its public API.


A module's name can be arbitrary. But to ensure uniqueness it is recommended to stick with the inverse-URL naming schema of packages. So while this is not necessary it will often mean that the module name is a prefix of the packages it contains.


A module lists the other modules it depends on to compile and run. This is true for application and library modules but also for modules in the JDK itself, which was split up into about 100 of them (have a look at them with java --list-modules). Again from the design overview:
When one module depends directly upon another in the module graph then code in the first module will be able to refer to types in the second module. We therefore say that the first module reads the second or, equivalently, that the second module is readable by the first. [...] The module system ensures that every dependence is fulfilled by precisely one other module, that the module graph is acyclic, that every module reads at most one module defining a given package, and that modules defining identically-named packages do not interfere with each other.
When any of the properties is violated, the module system refuses to compile or launch the code. This is an immense improvement over the brittle classpath, where e.g. missing JARs would only be discovered at runtime, crashing the application. It is also worth to point out that a module is only able to access another's types if it directly depends on it. So if A depends on B, which depends on C, then A is unable to access C unless it requires it explicitly.


A module lists the packages it exports. Only public types in these packages are accessible from outside the module. This means that public is no longer really public. A public type in a non-exported package is as inaccessible to the outside world as a non-public type in an exported package. Which is even more inaccessible than package-private types are before Java 9 because the module system does not even allow reflective access to them. As Jigsaw is currently implemented command line flags are the only way around this.


To be able to create a module, the project needs a module-info.java in its root source directory:
module advent {
    // no imports or exports
Wait, didn't I say that we have to declare dependencies on JDK modules as well? So why didn't we mention anything here? All Java code requires Object and that class, as well as the few others the demo uses, are part of the module java.base. So literally every Java module depends on java.base, which led the Jigsaw team to the decision to automatically require it. So we do not have to mention it explicitly. The biggest change is the script to compile and run (commands for Java 9):
# compile (include module-info.java)
javac -d classes/advent ${source files}
# package (add module-info.class and specify main class)
jar --create \
	--file=mods/advent.jar \
	--main-class=advent.Main \
	${compiled class files}
# run (specify a module path and simply name to module to run)
java --module-path mods --module advent
We can see that compilation is almost the same - we only need to include the new module-info.java in the list of classes. The jar command will create a so-called modular JAR, i.e. a JAR that contains a module. Unlike before we need no manifest anymore but can specify the main class directly. Note how the JAR is created in the directory mods. Utterly different is the way the application is started. The idea is to tell Java where to find the application modules (with --module-path mods, this is called the module path) and which module we would like to launch (with --module advent). jigsaw-demo-hands-on

Splitting Into Modules

Now it's time to really get to know Jigsaw and split that monolith up into separate modules.
Nicolai Parlog, Feb 01

Java's Switch Statement in Three Minutes

Java's switch statement allows easy selection of execution paths based on a variable's value. Switches can replace if-else-if chains.
Alejandro Gervasio, Jan 30

Using CDI/Weld to Inject JPA/Hibernate Entity Managers

A tutorial on how to use Contexts and Dependency Injection (CDI) / Weld and Hibernate in the development of a full-blown JPA application.
Ivan Mushketyk, Jan 23

Declutter Your POJOs with Lombok

Lombok is a library that helps to reduce Java's verbosity. This tutorial presents how to use it to write clearer POJO classes.
Gregor Trefs, Jan 16

Property Based Testing with Vavr

Learning property based testing, or property checking, in Java using Vavr (formerly Javaslang) and the FizzBuzz Kata.
Rafael Winterhalter, Jan 09

Fixing Bugs in Running Java Code with Dynamic Attach

Using Java agents and the dynamic attach and instrumentation APIs it is possible to fix bugs in running Java programs.
Thorben Janssen, Jan 02

10 Java Blogs to Follow in 2017

Stay ahead of the curve in 2017 by reading high quality posts on a regular basis. Here are 10 great Java blogs to get you started.