Java Next!

New Releases, Amber, Valhalla, and More Goodies

Nicolai Parlog

codefx.org / @nipafx

JUG Hessen

#JUGH

Lots to talk about!

Versions and Features
The New World
Projects To Look Out For

Slides at slides.codefx.org.

Versions and features

Versions and Features
The New World
Projects To Look Out For

From Java 8 to Java 13.

Java 8

  • released 03/2014

  • free support by Oracle ended 01/2019

  • free support by Red Hat until 06/2023

The core of Java 8

  • n -> lambdas()
    Method::references

  • features.stream()

  • default method() { …​ }

Project Lambda

Project Lambda

  • launched with a straw-man (12/2009):

    #(int x, int y)(x * y)

  • 1st early draft review (11/2011):

    Callable<String> c = () -> "done";

  • 2nd review (06/2012) and 3rd review (01/2013)

  • public review (12/2013) and final ballot (02/2014)

Projects…​

  • start with an idea
    that is then evolved

  • can take a long time

  • are fairly open

Java 9

  • released 09/2017

  • support ended 01/2018

The core of Java 9

About JPMS

More About JPMS

40% off with
code mtpvjug19

I’ve written a book!
tiny.cc/jms

  • creating, building,
    running modules

  • migration to Java 9+

  • modularization

  • services and
    advanced features

  • reflection and layers

  • custom runtime images

Project Jigsaw

Project Jigsaw

From Mark Reinhold’s announcement:

Sun’s primary goal in the upcoming JDK 7 release will be to modularize the JDK […​], which we hope to deliver early in 2010.

😊

Java 9 history

  • Java 9 release was planned for 09/2016

  • Jigsaw delays it to 03/2017,
    then 07/2017, then 09/2017

  • public review ballot (05/2017)

Java 9 history

  • public review ballot fails (05/2017)

  • various fundamental changes requested;
    only change: encapsulation turned off

  • reconsideration ballot passes (06/2017)

¯\_(ツ)_/¯

Projects…​

  • can lead to very heated discussions

  • are subject to politics

  • take feedback into account and
    adapt to new requirements

  • are not as open as they could be

  • can take a very long time and
    delay Java releases

Java 10

  • released 03/2018

  • support ended 07/2018

The core of Java 10

About var

Blog post:
First Contact With var In Java 10

Video:

youtube.com/codefx

Project Amber

More on that later!

Java 11

  • released 09/2018

  • free support by Oracle ended 01/2019

  • free support by Red Hat until 10/2024

The core of Java 11

Err…​

Isn’t that awesome?

Java 11

  • no language changes

  • no monumental dev-facing features

  • this will become common

  • that’s not a bad thing!

Java 12

  • release 03/2019

  • support ends 07/2019

The core of 12

  • preview on switch expressions:

    DayOfWeek day = // ...
int numLetters = switch (day) {
	case MONDAY, FRIDAY, SUNDAY -> 6;
	case TUESDAY -> 7;
	case THURSDAY, SATURDAY -> 8;
	case WEDNESDAY -> 9;
};

More about switch

Blog post:
Definitive Guide To Switch Expressions

Video:

youtube.com/codefx

Project Amber

No, even later…​

Java 13

  • release 09/2019

  • support ends 01/2020

The core of 13

  • preview on text blocks:

    String html = """
	<html>
		<body>
			<p>"Hello, text blocks!"</p>
		</body>
	</html>
	"""

More about text blocks

Blog post:
Definite Guide To Text Blocks

Project Amber

I said later!

The new world

Versions and Features
The New World
Projects To Look Out For

The new world

  • OpenJDK is the default
    (not Oracle JDK)

  • major release every 6 months
    (not every 2-5 years)

  • only selected versions get LTS
    (not all of them)

What’s OpenJDK?

OpenJDK is Java’s reference implementation:

  • a project

  • a code base

It doesn’t ship binaries, but others do:

OpenJDK vs Oracle JDK

Sun/Oracle JDK used to…​

  • contain more features

  • be perceived as more stable

  • be perceived as more performant

As of Java 11, on a technical basis,
Oracle JDK and OpenJDK are identical. *

OpenJDK vs Oracle JDK

Only difference is license and support model:

  • Oracle’s OpenJDK: licensed under GPL+CE

  • Oracle JDK is fully commercial:
    from 11 on, no free use in production

⇝ OpenJDK is the new default!
(Java is still free)

(More on support later…​)

More releases?

The old plan:

  • releases are driven by flagship features

  • new major release roughly every 2 years

The old reality:

  • Java 7 took 5 years

  • Java 8 took 3 years

  • Java 9 took 3.5 years

"Bump an 'almost ready' feature
2+ years into the future?"

⇝ "Better to delay the release."

Downsides

  • implemented features provide no value

  • increases reaction time

  • puts (political) pressure on projects

  • makes everybody grumpy

More releases!

If it hurts, do it more often.

  • fixed six-month release cadence
    (March and September)

  • ship everything that is ready

All are major releases
with known quality guarantees.

⇝ No "beta versions"!

Upsides

  • completed features get out earlier

  • no pressure to complete features on time

  • easier to react to changes in the ecosystem

  • easier to incubate features

Incubate features?

Two concepts allow features to incubate:

Features are shipped for experimentation.

There are safeguards against accidental proliferation.

Release fatigue?

"Java will change too fast."

"Test matrix will explode."

"Ecosystem will fragment."

"Constant migrations will be expensive."

What is LTS?

To discuss long-term support,
lets look at JDK development:

  • there’s the OpenJDK code base at
    hg.openjdk.java.net/jdk/jdk/

  • there are many clones:

    • for each JDK release

    • for each JDK project

    • each vendor has their own

OpenJDK development

A new feature, simplified:

  • developed in "feature branch"

  • merged into "master" when (nearly) finished

A release, simplified:

  • "release branch" created 3 months prior

  • only bug fixes merged to "release branch"

A bug/security/etc fix, simplified:

  • usually developed in "master"

  • merged into relevant release branches

OpenJDK support

Support really means:

  • fixing bugs, usually in "master"

  • merging fixes to "release branches"

How does Oracle handle that?

  • work on "master" in OpenJDK

  • merge to current "release branch" in OpenJDK

  • merge to LTS version in Oracle JDK

Long-term support

What’s left for long-term support?

⇝ Merging fixes into old JDK versions.

Commercial LTS

Free LTS

Long-term support for OpenJDK:

Free LTS

Other players:

More?

Staying on Java 11 LTS

I’d love for everyone
to always be up to date.

But:

Going from Java 11 to 12
is not without risks.

😢

Risks for Java 12-16

Lack of support for 12-16:

  • free support is very unlikely

  • commercial support is rare
    (Azul offers MTS for 13 and 15)

Without support, you have to upgrade
to each major version immediately!

Risks for Java 12-16

What could possibly go wrong?!

Before you upgrade to Java 12:

  1. read Should you adopt Java 12 […​]?
    by Stephen Colebourne

  2. take a coffee break

  3. understand that most risks come
    from building against 12

  4. be content that all you need
    to upgrade is run on 12

Risks for Java 12-16

What could possibly go wrong?!

  • remember @Deprecated(forRemoval=true)?

  • changes to unsupported APIs, e.g. Unsafe

Problems are not likely,
but usually hard to predict.

⇝ Chance is low.

Risks for Java 12-16

If an upgrade fails,
you have two choices:

  • run on an unsupported (unsecure) JVM 😮

  • downgrade to recent LTS 😱

⇝ Damage is potentially enormous.

Risks for Java 12-16

expected_damage = chance * damage

Consider this:

  • more up-to-date ⇝ lower chance

  • fewer dependencies ⇝ lower chance

  • smaller code base ⇝ smaller damage

Advice

  • find a suitable upgrade cadence

  • build on each release (including EA)

  • only rely on standardized behavior

  • heed deprecation warnings (jdeprscan)

  • keep dependencies and tools up to date

Most importantly:
Be aware of what’s coming!

Projects

Versions and Features
The New World
Projects To Look Out For

Many great features on the horizon!

Be aware

Don’t focus on versions!

Focus on projects and JEPs:

  • large features are developed by projects

  • smaller features are proposed by JEP only

Let’s have a look at what’s coming!

(Straw-man syntax ahead!)

Many great projects

  • Amber: smaller, productivity-oriented features

  • Valhalla: generic specialization and value types

  • Loom: fibers and continuations

  • Metropolis: Graal and ahead-of-time compilation

  • Panama: improved interaction with non-Java code

Project Amber

Smaller, productivity-oriented Java language features

Profile:

Motivation

Java compared to more modern languages:

  • can be cumbersome

  • lacks expressiveness

  • tends to require boilerplate

Amber wants to improve that situation!

Delivered

  • local-variable type inference with var
    (JEP 286; in Java 10)

  • switch expressions
    (JEP 325; preview in Java 12 and 13)

  • text blocks
    (JEP 355; preview in Java 13)

Endeavors

Pattern matching

Object value = // ...
String formatted = switch (value) {
	case Integer i -> String.format("int %d", i);
	case Byte b    -> String.format("byte %d", b);
	case Long l    -> String.format("long %d", l);
	case Double d  -> String.format("double %f", d);
	case String s  -> String.format("String %s", s);
	default        -> "unknown " + value.toString();
};

Yeah:

  • more powerful conditions

  • no repetition between condition and block

Pattern matching

public int eval(Node n) {
	return switch(n) {
		case IntNode(int i) -> i;
		case NegNode(Node n) -> -eval(n);
		case AddNode(Node left, Node right) ->
			eval(left) + eval(right);
	};
}

Yeah:

  • deconstructing complex objects

  • goodbye visitor pattern!

Records

public record Range(int low, int high) {

	// compiler generates:
	//  * constructor, deconstructor
	//  * equals/hashCode/toString
	//  * accessors low(), high()

}

Yeah:

  • no boilerplate for plain "data carriers"

  • no room for error in equals/hashCode

  • makes Java more expressive

Records

The API for a record models the state, the whole state, and nothing but the state.

The deal:

  • give up encapsulation

  • couple API to internal state

  • get API for free

Customized records

public record Range(int low, int high) {

	// compiler knows signature and assigns to fields
	public Range {
		if (low > high)
			throw new IllegalArgumentException();
	}

	public void setLow(int low) {
		if (low > this.high)
			throw new IllegalArgumentException();
		this.low = low;
	}

}

Sealed types

Have a closer look at the cases:

public int eval(Node n) {
	return switch(n) {
		case IntNode(int i) -> // ...
		case NegNode(Node n) -> // ...
		case AddNode(Node left, Node right) -> // ...
	};
}

Why is there no default branch?

Sealed types

public sealed interface Node
	permits IntNode, NegNode, AddNode {

	// interface declaration

}

Yeah:

  • code expresses intended subtypes

  • pattern matching can check completeness

Death to serialization!

Serialization is hell:

  • complicates every JDK feature

  • repeated security vulnerabilities

  • uses "invisible" mechanisms

The JDK team wants to get rid of it!

Serializing records

Replacement may look as follows:

  • only works with records

  • deconstructs a record graph

  • passes data to serialization engine

  • one engine per format:
    XML, JSON, YAML, …​

New serialization

Yeah:

  • records are a great fit for serialization

  • new mechanism uses (de)constructors

  • superior maintainability

Concise method bodies

class ListWrapper<E> implements List<E> {

    private List<E> list;

    public int size() -> list.size();
    public T get(int index) -> list.get(index);
	public int indexOf(E el) = list::indexOf;

}

Yeah:

  • simple methods get simple code

  • fewer (empty) lines

Raw string literals

String regex = \"\+(\d*[.])?\d"

Yeah:

  • no escaping of special characters

But:

Turns out, it’s complicated. 😁

Raw multi-line strings

Maybe?

String yaml = \"""
	name: "Positive number"
	regex: "\+(\d*[.])?\d"
	""";

Project Amber

Makes Java more expressive:

  • type inference with var ⑩

  • switch expressions ⑫

  • text blocks ⑬

  • pattern matching

  • records

  • sealed types

  • serialization revamp

  • concise method bodies

  • raw string literals

Project Valhalla

Advanced Java VM and Language feature candidates

Profile:

Motivation

In Java, (almost) everything is a class:

  • mutable by default

  • memory access indirection

  • requires extra memory for header

  • allows locking and other
    identity-based operations

Wouldn’t it be nice to create a custom int?

Value types

public value Range {

	// implicitly final
	private int low;
	private int high;

	// you write:
	//  * constructor, static factories
	//  * equals/hashCode/toString
	//  * accessors, etc.

}

Value types

public value Range {
	private int low;
	private int high;
}

Yeah:

  • enforced immutability

  • no memory indirection! (flat)

  • no Object header! (dense)

  • makes Java more expressive

Value types

Codes like a class, works like an int.

The deal:

  • give up identity / mutability
    (and self references)

  • get flat and dense memory layout

Values vs Records

Values

no identity / mutability
⇝ flat and dense memory layout

Records

no encapsulation
⇝ less boilerplate

Might be combinable to "value records".

Generic specialization

When everybody creates their own "primitives",
boxing becomes omni-present and very painful!

List<int> ids = new ArrayList<>();

Yeah:

  • backed by an actual int[]

  • great performance

  • works with your value types

Put together

Value types and generic specialization together,
have immense effects inside the JDK!

  • no more manual specializations:

    • functional interfaces

    • stream API

    • Optional API

  • better performance

Put together

Value types and generic specialization together,
have immense effects on your code!

  • fewer trade-offs between
    design and performance

  • better performance

  • can express design more clearly

  • more robust APIs

Project Valhalla

Makes Java more expressive and performant:

  • value types

  • primitive specialization

Project Loom

Fibers, delimited continuations, explicit tail-call

Profile:

Motivation

Imagine a hypothetical request:

  1. interpret request

  2. query database (blocks)

  3. process data for response

JVM resource utilization:

  • good for tasks 1., 3.

  • really bad for task 2.

How to implement that request?

Motivation

Synchronous (simple)

  • thread per request

  • blocks on certain calls

  • bad thread utilization

Asynchronous (not so simple)

  • use non-blocking APIs with futures

  • incompatible with synchronous code

  • great thread utilization (scalable!)

Enter fibers!

A fiber:

  • looks like a thread to devs

  • low memory footprint ([k]bytes)

  • small switching cost

  • scheduled by the JVM

Fiber management

The JVM manages fibers:

  • runs them in a pool of carrier threads

  • makes fibers yield on blocking calls
    (frees the carrier thread!)

  • continues fibers when calls return

Fiber example

Remember the hypothetical request:

  1. interpret request

  2. query database (blocks)

  3. process data for response

In a fiber:

  • JVM submits fiber to thread pool

  • when 2. blocks, fiber yields

  • JVM hands thread back to pool

  • when 2. unblocks, JVM resubmits fiber

  • fiber continues with 3. (how?)

Fibers

Yeah:

  • great thread utilization

  • code is written/debugged as if synchronous

  • legacy code may be forward compatible

Continuations

How do fibers continue?

  • use continuations (low-level API)

  • JVM stores and restores call stack

Project Loom

Makes threading more pleasant:

  • simple programming model

  • great thread utilization

Projects

To know what’s coming:

  • pick a project that interests you

  • look out for mentions

  • subscribe to the mailing list

  • find early access builds and try them

  • give feedback

Tell your colleagues about it!

About Nicolai Parlog

37% off with
code fccparlog

tiny.cc/jms

Follow

💻 codefx.org
🐦 @nipafx

Want More?

Slides at slides.codefx.org

⇜ Get my book!

You can hire me:

  • training (Java 8-12, JUnit 5)

  • consulting (Java 8-12)

Image Credits

Image Credits