Java Next!

New Releases, Amber, Valhalla, and More Goodies

Nicolai Parlog

codefx.org / @nipafx

Java Saigon

#JavaSaigon

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 12.

Java 8

  • released 03/2014

  • free support by Oracle ends 01/2019

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

  • free support ended 01/2018

The core of Java 9

About JPMS

More About JPMS

37% off with
code fccparlog

I’ve written a book!
E-book available ⇝ 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.

😊

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)

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)

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

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

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

About switch

Blog post:
Definitive Guide To Switch Expressions In Java 12

Video:

youtube.com/codefx

Project Amber

No, even later…​

The new world

Versions and Features
The New World
Projects To Look Out For

Old release cadence

The plan

  • releases are driven by flagship features

  • new major release roughly every 2 years

Old release cadence

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

Yes, Java 9 migration is tough!

But not the norm:

  • Java 10 is trivial

  • Java 11 is easy

Oracle is still committed
to backwards compatibility!

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

Incubating features?

Two concepts allow features to incubate:

Both have safeguards against accidental proliferation.

Expensive migrations

Remedies:

  • stick to supported APIs

  • stick to standardized behavior

  • stick to well-maintained projects

  • keep dependencies and tools up to date

  • consider using jlink

Exploding test matrix

As the range of supported versions increases…​

  • builds need to run against all of them

  • developers need 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

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. *

Oracle JDK vs OpenJDK

Only difference is license and support model:

  • Oracle ships OpenJDK at jdk.java.net,
    licensed under GPL+CE

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

⇝ OpenJDK is the new normal!

Oracle support

What does Oracle support?

  • free updates for current OpenJDK version
    (i.e. six months)

  • commercial support for Oracle JDK
    for 5+ years for Java 11, 17, 23, etc.
    (called Java SE Subscription; prices)

⇝ 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 (Oracle JDK)

⇝ "LTS" means merging fixes
into old JDK versions.

Commercial LTS

Free LTS

Free long-term support:

  • for OpenJDK 11, 17, 23, etc.
    by the community for 4+ years

  • for 11, under the guidance of Red Hat

  • built and shipped by Adopt OpenJDK

Free LTS

[L]et me assure you of one thing: whether by Oracle or Red Hat or someone else, JDK LTS releases will continue to be supported. We all have a lot invested in Java, and we won’t let it fall.

— Andrew Haley, Red Hat (link)

Free LTS

One other player:

Amazon Corretto is a no-cost, multiplatform, production-ready distribution of the Open Java Development Kit (OpenJDK). Corretto comes with long-term support that will include performance enhancements and security fixes.

Free LTS

Corretto:

  • builds on OpenJDK

  • contains additional security
    and stability fixes by Amazon

It is updated quarterly:

  • Java 8 until at least 06-2023

  • Java 11 until at least 08-2024

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)

Endeavors

Raw string literals

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

Yeah:

  • multiline strings

  • no escaping of special characters

Preview in Java 13.

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

Node n = // ...
int result = 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;
	}

}

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 serilization 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

Project Amber

Makes Java more expressive:

  • type inference with var ⑩

  • switch expressions ⑫

  • raw string literals ⑬

  • pattern matching

  • records

  • serialization revamp

  • concise method bodies

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
▶ 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

Image Credits