Java Next!

New Releases, Amber, Valhalla, and More Goodies

Lots to talk about!

Versions and Features
The New World
Projects To Look Out For

If you’re shy, tweet questions
with #JavaNext

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

  • free support ended 01/2018

What’s the core of 9?

More on the JPMS

37% off with
code fccparlog

tiny.cc/jms

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

  • lacking module isolation

  • forbidden cyclic dependencies

  • the concept of automatic modules

  • migration challenges

  • and a few more

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)

  • 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

  • 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?

Err…​

  • single-file source-code programs:

    java HelloWorld.java
  • 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."

Downsides

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

Implementation

  • features are developed in branches

  • merged into master when (nearly) finished

  • release branch created 3 months prior

  • only bug fixes merged to release branch

Upsides

  • 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

Remedies:

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

No.

Advice

  • find a suitable update cadence

  • build on each release (including EA)

  • report problems

  • only rely on standardized behavior

  • heed deprecation warnings (jdeprscan)

  • keep dependencies and tools up to date

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 jdk.java.net/$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.

⇝ No Free LTS by Oracle.

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!

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 language features

Valhalla

Generic specialization and value types

Loom

Fibers and continuations

Metropolis

Graal and ahead-of-time compilation

Sumatra

Java on the GPU and APU

Project Amber

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

Profile:

Already delivered var in Java 10!

Motivation

Java compared to more modern languages:

  • can be cumbersome

  • lacks expressiveness

  • tends to require boilerplate

Amber wants to improve that situation.

Endeavors

Raw string literals

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

Yeah:

  • multiline strings

  • no escaping of special characters

Switch expressions

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

Yeah:

  • switch "gets a value"

  • no more break!

  • compiler checks exhaustiveness

Pattern matching

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);
		default -> throw new IllegalStateException(n);
	};
}

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;
	}

}

Project Valhalla

Explore and incubate 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 Point {

	private final int x;
	private final int y;

	// constructor, accessors,
	// equals/hashCode/toString,
	// and other methods

}

Codes like a class, works like an int.

Value types

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

Yeah:

  • enforced immutability

  • no memory indirection! (flat)

  • no Object header (dense)

  • identity doesn’t matter

  • makes Java more expressive

Values vs Records

Values:

  • no identity

  • no self references

  • no 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 Sumatra

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

Profile:

Motivation

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

Goals

Basics:

  • create low-level API to uniformly access GPUs

  • use streams as high-level API

Goals

Ideally:

  • 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

Implementation

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!

Example

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];

	// ...

}

Example

// 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 -> {
	System.out.println(
		out[p] + ", " + ina[p] + ", " + inb[p]);
});

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
▶ youtube.com/c/codefx
🐦 @nipafx

Want More?

⇜ Get my book!

You can hire me:

  • training (Java 8-11, JUnit 5)

  • consulting (Java 8-11)

Image Credits