Java Next!

New Releases, Amber, Valhalla, and More Goodies

Lots to talk about!

Versions and Features
The New World
Projects To Look Out For

(Slides at

Versions and features

Versions and Features
The New World
Projects To Look Out For

From Java 8 to Java 11.

Java 8

  • released 03/2014

  • free support ends 01/2019

What’s the core of 8?

  • n -> lambdas()
    and Method::references


  • default method() { …​ }

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)

Project Lambda


  • start with an idea
    that is then evolved

  • can take a long time

  • are fairly open

Java 9

  • released 09/2017

  • free support ended 01/2018

What’s the core of 9?

More on the JPMS

37% off with
code fccparlog

Project Jigsaw

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


Jigsaw history

  • Oracle acquires Sun, Jigsaw is halted (2010)

  • Jigsaw starts exploratory phase (2011)

  • releases of Java 7 (2011) and Java 8 (2014)

  • exploratory phase ends with JSR 376 (2014)

  • a prototype is released (09/2015)

Community unrest

  • about lacking module isolation

  • about forbidden cyclic dependencies

  • about the concept of automatic modules

  • about migration challenges

Community unrest

  • about Unsafe et. al.
    ⇝ jdk.unsupported exports them

  • about strong encapsulation
    ⇝ deactivated on JDK 9/10/11

  • about hostility to reflection
    ⇝ opens directive

  • and a few more

Jigsaw 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)

Jigsaw history

  • public review ballot fails (05/2017)

  • only change: encapsulation turned off

  • reconsideration ballot passes (06/2017)



  • 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

  • free support ends 07/2018

What’s the core of 10?

Project Amber

More on that later!

Java 11

  • release 09/2018

  • free support ends 01/2019
    (yes, no free LTS—​more on that later)

What’s the core of 11?


  • single-file source-code programs:

  • reactive HTTP/2 client

  • Epsilon GC

Java 11

  • no language changes

  • no monumental dev-facing features

  • this will become common

  • that’s not a bad thing!

The new world

Versions and Features
The New World
Projects To Look Out For

Old release cycle

The plan

  • releases are driven by flagship features

  • new major release roughly every 2 years

Old release cycle

The 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."


  • implemented features provide no value

  • increases reaction time

  • puts (political) pressure on projects

  • makes everybody grumpy

The new world

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"!


  • features are developed in branches

  • merged into master when (nearly) finished

  • release branch created 3 months prior

  • only bug fixes merged to release branch


  • completed features get out earlier

  • no pressure to complete features "on time"

  • easier to incubate features

  • easier to react to changes in the ecosystem

Release fatigue?

"Java will change too fast."

"Constant migrations will be expensive."

"Test matrix will explode."

"Ecosystem will fragment."

Fast Change

The rate of innovation doesn’t change. The rate of innovation delivery increases.

— Mark Reinhold

Maybe speed will pick up a little:

  • recent activities target low-hanging fruits

  • Oracle is focusing on Java core (my impression!)

Fast Change

By and large:

Evolution will be steadier, not faster.

(see Java 11)

Expensive migrations

Balance shifted between
compatibility vs evolution:

  • @Deprecated(forRemoval=true)

  • "one major release" is now 6 months, not 36

  • increasing bytecode level

  • incubating features (if used incorrectly)

Expensive migrations

But not the norm:

  • Java 10 is trivial

  • Java 11 is easy

Oracle is still committed
to backwards compatibility!

Expensive migrations


  • stick to supported APIs

  • stick to standardized behavior

  • stick to well-maintained projects

  • keep dependencies and tools up to date

Exploding test matrix

As the range of supported versions increases…​

  • builds need to run against all of them

  • developers needs to switch between them

Many tools already support this.
We need to know how.

Also: Moar automization!

Fragmenting Ecosystem

"This will be like Python 2/3!"



  • find a suitable update cadence

  • test with each feature release

  • only rely on standardized behavior

  • heed deprecation warnings

  • keep dependencies and tools up to date

  • give jlink a try

Most importantly:
Be aware of what’s coming!

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!

Long-term support

What if you (or your customers)
don’t want to update every six months?

Oracle JDK vs OpenJDK

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.

Oracle JDK vs OpenJDK

Only difference is license and support model:

  • Oracle ships OpenJDK at$version,
    licensed under GPL+CE

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

⇝ Get used to using on OpenJDK.

Oracle support

What does Oracle support?

  • free updates for current major OpenJDK version

  • commercial support for Oracle JDK
    for at least 3 years for Java 11, 17, 23, etc.

Oracle support

How does Oracle handle bug/security/etc fixes?

  • usually developed on master (OpenJDK)

  • merged to current version’s branch (OpenJDK)

  • merged to current LTS version (internally)

LTS means merging fixes
into old OpenJDK branches.

Long-term support

Commercial LTS by

  • Oracle

  • Azul

  • RedHat

  • …​

Likely free LTS for OpenJDK
by Adopt OpenJDK!



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


Smaller, productivity-oriented language features


Generic specialization and value types


Fibers and continuations


Graal and ahead-of-time compilation


Java on the GPU and APU


Explore and incubate smaller, productivity-oriented Java language features.


Already delivered var in Java 10!


Compared to modern languages, Java:

  • can be cumbersome

  • lacks expressiveness

  • tends to require boilerplate

Amber wants to improve that situation.


String literals

String html =
			<p>"Hello, string literals!"</p>


  • multiline strings

  • no escaping of special characters

Switch expressions

int numLetters = switch (day) {
	case TUESDAY -> 7;
	case WEDNESDAY -> 9;


  • switch "gets a value"

  • no more break!

  • compiler checks exhaustiveness

Pattern matching

String formatted = switch (obj) {
	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        -> obj.toString();


  • 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);
		case MulNode(Node left, Node right) ->
			eval(left) * eval(right);
		default -> throw new IllegalStateException(n);

Goodbye visitor pattern!


Explore and incubate advanced Java VM and Language feature candidates.



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

Codes like a class, works like an int.

public value Point {

	public final int x;
	public final int y;

	public Point(int x, int y) {
		this.x = x;
		this.y = y;


Value types

public value Point {
	public final int x;
	public final int y;

	// [...]



  • enforced immutability

  • no Object header

  • identity doesn’t matter

  • makes Java more expressive (think DDD)

Generic specialization

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

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


  • backed by an actual int[]

  • great performance

Generic specialization

Has immense effect inside the JDK!

No more manual specializations:

  • functional interfaces

  • stream API

  • Optional API

  • etc.


Enable Java applications to take advantage of GPUs and APUs […​] to improve performance



Why use the GPU?

  • can be more peformant

  • can be more energy-efficient

Can’t we do that already?
(Aparapi, JOCL)

  • not integrated into the JDK

  • require their own programming model



  • create low-level API to uniformly access GPUs

  • use stream API as high-level API


  • auto-detection of hardware and software stack

  • heuristic to decide when offloading makes sense

  • offload embarrassingly parallel stream pipelines

  • on error, graceful fall-back to normal CPU execution


For stream operations to offload:

  • extract lambda function

  • use Graal to compile to HSA kernel (runs on GPU)

  • extract lambda arguments and pass to HSA

GPU operates on main memory
and has access to Java heap!


public static void main(String[] args) {

	final int length = 8;
	int[] ina = new int[length];
	int[] inb = new int[length];
	int[] out = new int[length];

	// ...



// offloadable
IntStream.range(0, length).parallel().forEach(p -> {
	ina[p] = 1;
	inb[p] = 2;

// offloadable
IntStream.range(0, length).parallel().forEach(p -> {
	out[p] = ina[p] + inb[p];

// not offloadable (native code)
IntStream.range(0, length).forEach(p -> {
		out[p] + ", " + ina[p] + ", " + inb[p]);


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


🐦 @nipafx

Want More?

β‡œ Get my book!

You can hire me:

  • training (Java 8-11, JUnit 5)

  • consulting (Java 8-11)

Image Credits