OpenJDK Projects you should know about: Amber

This month we are focusing on OpenJDK projects you should know about.

So far we have already covered Valhalla, Panama, Loom, and Skara. This time we will be covering what Project Amber is, the features already added to improve productivity and what’s in progress.

What is Project Amber?

Project Amber relates to several small features which are being added to the JDK over time.

The aim of the project is to improve productivity for Java developers by making coder easier to write and maintain. Its features were chosen with 3 key principles in mind: readability, simplicity and transparency. Particular focus is given to making code more readable, as this in turn makes it easier to maintain. Project Amber is adding features that lets you write shorter, cleaner code with less boilerplate.

What has already been done?

You have probably already heard about the 2 features that have already been delivered as part of Project Amber. These are:

Local Variable Type Inference

You can now declare and initialise local variables with var. This was added to the JDK in Java 10. For example you can now do:

var x = 7;

Local Variable Syntax for Lambda Parameters

You can now use var for declaring parameters inside implicitly typed lambda expressions. This was added in Java 11. For example you can now do:

(var y) -> y.doSomething();

What features are in progress?

There are also several features of Project Amber still in progress. These include:

Lambda Leftovers

This JEP covers 2 main improvements to lambda expressions.

1. Allowing underscores to be used for unnamed lambda parameters. For example if the lambda is implementing an abstract method that takes two arguments, but only one is needed for your use case, you will be able to use ‘_’ to fill the place of the one you don’t need.
2. Shadowing of parameters in lambda expressions. Currently if you define a variable called ‘x’ inside a method, you would not be able to use ‘x’ as the name of a lambda parameter inside that method. This JEP will allow you to reuse variable names.

There is a third improvement covered too, better disambiguation for functional expression. The aim of this is to improve type checking in lambdas. However this is currently an optional suggestion, because it depends on the impact on the compiler implementation, which is still to be tested.

Pattern Matching

It is common in Java to have something like the below code, which checks for the type of an object and then casts it to the correct type and then uses that information to extract some more information from it:

if (obj instanceof Integer) {
    int intValue = ((Integer) obj).getIntValue;
} else if (obj instanceof Long) {
     long longValue = ((Long) obj).getLongValue;
} else if (obj instanceOf Double) {
     double doubleValue = ((Double) obj).getDoubleValue;
} .....

There is a lot of boilerplate code here which makes it difficult to see what the actual purpose of the code is. Pattern matching will allow code like this to become shorter and easier to read. There are a number of different types of pattern that can be used for matching, which can be read about in much more detail here.

Data Classes

A common complaint about Java is that it is very verbose.  Just to print out ‘Hello World’ requires a surprising amount of code. Data classes would let you very concisely create new classes, e.g.:

record Point(int x, int y) { }

The drawback is that there is a lack of consensus on exactly how it would work, and what restrictions should be accepted.

These are just a few of the proposed features in Project Amber. There are several more small features that are yet to be implemented.

Where can I find out more?

OpenJDK page

Document on Data Classes

Local Variable Type Inference FAQs

Brian Goetz’s talk at Devoxx 2017

What do you think of Project Amber? Let us know in the comments.

Our software libraries allow you to