The document summarizes highlights from Java versions 10 through 13 and discusses the future of Java, including projects Valhalla, Loom, and GraalVM. It outlines new features in Java 10-13 like local variable type inference, garbage collector improvements, switch expressions, and HTTP client. It then discusses Project Valhalla which aims to introduce value types to improve performance by reducing memory usage and indirection. It also covers Project Loom which explores lightweight user-mode threads called fibers and continuations to enable simpler concurrent programming. Finally, it discusses GraalVM and how it provides a high performance runtime for multiple languages with low overhead interoperability between languages.

1. Highlights from Java 10-13
and Future of Java
JCON 25.09.2019
by Rodion Alukhanov and Vadym Kazulkin, ip.labs GmbH

2. Contact
Vadym Kazulkin, ip.labs GmbH
v.kazulkin@iplabs.de
www.xing.com/profile/Vadym_Kazulkin
@VKazulkin, @ServerlessBonn (Meetup)
Rodion Alukhanov, ip.labs GmbH
r.alukhanov@iplabs.de
www.xing.com/profile/Rodion_Alukhanov

3. ip.labs GmbH

4. Agenda
● Highlights from Java 10-13
● Project Valhalla (Value Types)
● Project Loom (Fibers and Continuations)
● GraalVM

5. Project Amber
Local-Variable Type Inference (JEP 286, JDK 10)
URL url = new URL("https://javapro.io/neues-in-java-13");
URLConnection connection = url.openConnection();
try (InputStream s1 = connection.getInputStream()) {
IOUtils.copy(s1, System.out);
};
var url = new URL("https://javapro.io/neues-in-java-13");
var connection = url.openConnection();
try (var s1 = connection.getInputStream()) {
IOUtils.copy(s1, System.out);
};

6. var var = 19;
var b = null; // Compilation error
var c = 1; d = 1; // Compilation error
Project Amber
Local-Variable Type Inference (JEP 286, JDK 10)
var a = new ArrayList<>(); // list of <Object>
BiFunction<Integer, Integer, Integer> f1 =
(var a, var b) -> a + b; // since Java 11
var f2 = (var a, var b) -> a + b; // Compilation error

7. Consumer<String> a = getBuffer(); // Consumer or Supplier, never both
a.accept("variable of two types");
Supplier<String> b = (Supplier<String>)a;
System.out.print(b.get());
Project Amber
Local-Variable Type Inference (JEP 286, JDK 10)
// Tricky way to declare "Consumer & Supplier" type
public <T extends Consumer<String> & Supplier<String>> T getBuffer() {
return (T)new Buffer();
}
var a = getBuffer();
a.accept("variable of two types");
System.out.print(a.get());

8. Garbage Collector Interface (JEP 304, JDK10)
ZGC: A Scalable Low-Latency Garbage Collector (Experimental),
(JEP 333, JDK11)
Epsilon: A No-Op Garbage Collector (Experimental),
(JEP 318, JDK11)
Shenandoah: A Low-Pause-Time Garbage Collector (Experimental),
(JEP189, JDK 12)
Abortable Mixed Collections for G1 (JEP 344, JDK 12)
Promptly Return Unused Committed Memory from G1 (JEP 346, JDK 12)
ZGC: Uncommit Unused Memory, (JEP 351, JDK13)

9. String value = null;
switch (k) {
case 1: value = "one";
break;
case 2: value = "two";
break;
case 3:
case 4: value = “many";
break;
}
Switch Expressions (JEP 325, JDK 12 Preview),
Switch Expressions (JEP 354, JDK 13 Preview)
switch (k) {
case 1 -> value = "one";
case 2 -> value = "two";
case 3, 4 -> value = "many";
}
value = switch(k) {
case 1 -> "one";
case 2 -> "two";
case 3, 4 -> "many";
default -> {
yield null;
}
};

10. HTTP Client, (JEP 110, JDK 9 Incubator),
HTTP Client (JEP 321, JDK 11)
Some Features useful features:
+ HTTP/2 Support
+ Asynchronous requests
+ Stream, JDK Flow support
+ method chaining
HttpRequest request = HttpRequest.newBuilder()
.uri(URI.create("https://javapro.io/neues-in-java-13"))
.build();
HttpResponse<String> response =
httpClient.send(request, BodyHandlers.ofString());
logger.info("Response status code: " + response.statusCode());
logger.info("Response headers: " + response.headers());
logger.info("Response body: " + response.body());
- No URI building libraries
- No compression support
- No multipart form data parser
- No non-2xx to exception conversion

11. API: Unmodifiable Lists (JDK 10)
List.of(e1,e2,e3,e4...)
List.copyOf(copyMe)
Collectors.toUnmodifiableList()
// same for Set and Map
// copies only if needed
// java.lang.UnsupportedOperationException
// no Guava compatibility (as expected)

12. API: Support for Unicode White Spaces (JDK 11)
String.isBlank()
String.strip()
String.stripLeading()
String.stripTrailing()
String.repeat(count)
Character trimable stripable
U+0009, TAB yes yes
U+0020, SPACE yes yes
U+00A0 NO-BREAK SPACE no no
U+2000 EN QUAD no yes
U+200B ZERO WIDTH SPACE no no

13. Better Container-Awareness (Docker Issues)
Runtime runtime = Runtime.getRuntime();
int processors = runtime.availableProcessors();
long maxMemory = runtime.maxMemory();
4 CORES, 4Gb --cpus=2 --cpuset-cpus=0,1
JAVA8, runtime.availableProcessors 4 2
JAVA10, runtime.availableProcessors 2 2
4 CORES, 4Gb --memory=512m
JAVA8, runtime.maxMemory 1g (¼ of 4g)
JAVA9, runtime.maxMemory 128m (¼ of 512m)
Fix for JDK 8u131 (Issue JDK-8146115)
-XX:+UseCGroupMemoryLimitForHeap
-XX:+UnlockExperimentalVMOptions

14. Application Class Data Sharing, (JEP 310, JEP 341, JEP 350)
load class-file
from disk
verify byte-
code
optimize
put into internal
merory structure
- CDS (-Xshare:auto) // JDK5
- Application CDS // JDK 10
- CDS out-of-the-box // JDK 12
- Dynamic Application CSD (-XX:ArchiveClassesAtExit) // JDK 13
load dump from disk map RAM

15. Raw String Literals (JEP 326),
Text-Blocks (Preview), (JEP 355, JDK 13)
var html = """
...........<html>
........... <body>Hello, world</body>
...........</html>
...........""";
- Incidental white spaces are removed (shown as dots in the example)
- Trailing white spaces are removed
- Line breaks become LF (a.k.a. n) regardless of platform
- No incidential tabs support (checked using build 25)
- No variable place holder (as supported by Kotlin and Scala)

16. Project Valhalla
Value Types
Source: http://openjdk.java.net/projects/valhalla/

17. Project Valhalla
Goal:
● Reboot the layout of data in memory
Source: Brian Goetz, Oracle „Evolving the Java Language” https://www.youtube.com/watch?v=A-mxj2vhVAA

18. Project Valhalla
Motivation:
● Hardware has changed
– Multi-core
– The cost of cache misses has increased
Source: Brian Goetz, Oracle „Evolving the Java Language” https://www.youtube.com/watch?v=A-mxj2vhVAA

19. Project Valhalla
Motivation
Source: „Latency Numbers Every Programmer Should Know”
https://people.eecs.berkeley.edu/~rcs/research/interactive_latency.html

20. Project Valhalla
Motivation
Source: „Latency Numbers Every Programmer Should Know”
https://people.eecs.berkeley.edu/~rcs/research/interactive_latency.html

21. Project Valhalla
Storing objects in the Java Heap has its price, because object’s
metadata consumes additional memory for :
● flags facilitating synchronization/locking
● identity/polymorphismus
● garbage collection

22. Project Valhalla
Value Object
Value Object is an immutable type that is distinguishable only
by the state of its properties

23. Project Valhalla
Benefits:
● Reduced memory usage
● Reduced indirection
● Increased locality
Codes like a class, works like a primitive (Brian Goetz)

24. Project Valhalla
Source: „What Is Project Valhalla?” https://dzone.com/articles/what-is-project-valhalla

25. Project Valhalla
Value Types
inline class Point {long x, y ;}

26. Project Valhalla
Value Types
Can
● have method and field
● implement interfaces
● use encapsulation
● be generic
Can’t
● be mutated
● be sub-classed

27. Project Valhalla
Current Status:
● Released public prototype L2
– Can declare and use value types (inline classes)
– Can have erased generics over value types (analoguos to List<Integer>)
– Memory Layout optimizations implemented
– Compiler/Virtual Machine optimizations implemented
– A lot of challenges to solve (read the article https://www.infoq.com/news/2019/07/valhalla-
openjdk-lw2-released/)
Source: Brian Goetz, Oracle „Valhalla Update” https://www.youtube.com/watch?v=1H4vmT-Va4o

28. Project Valhalla
Open Questions:
● Nullity
● Equality
● Migration
● Specialized generics (Point<T>)
● GraalVM Support
Source: Brian Goetz, Oracle „Valhalla Update” https://www.youtube.com/watch?v=1H4vmT-Va4o

29. Project Loom
Fibers and Continuations
Source: http://openjdk.java.net/projects/loom

30. Project Loom
Motivation:
● Developers currently have 2 choices to write concurrent code:
– use blocking/synchronous API, which is simple, but less scalable (number of threads, that OS
supports is far less that open and concurrent connections required)
– asynchronous API (Spring Project Reactor, RXJava 2), which is scalable, but complex, harder to
debug and profile and limited (no asynchronous JDBC standard in this area)
Sources: Alan Bateman, Oracle „Project Loom: Fibers and Continuations for Java” https://www.youtube.com/watch?v=vbGbXUjlRyQ
“Spaghetti Code” https://exceptionnotfound.net/spaghetti-code-the-daily-software-anti-pattern/

31. Project Loom
Goals:
● explore Java VM features and APIs built on top of them for the
implementation of lightweight user-mode threads (fibers) and continuations

32. Project Loom
Continuation
Continuation is a program object, representing a computation
that may be suspended and resumed

33. Continuation
package java.lang;
public class Continuation {
public Continuation (ContinuationScope scope, Runnable target)
public final void run()
public static void yield (ContinuationScope scope)
public boolean isDone()
}
http://hg.openjdk.java.net/loom/loom/file/27a4185098e8/src/java.base/share/classes/java/lang/Continuation.java

34. Project Loom
Fibers
Fibre is a lightweight thread scheduled not by the OS, but by
the Java Runtime with low memory footprint and low task-
switching cost

35. Project Loom
Fibers & Continuations
Fiber
=
Continuation + Schedular

36. Project Loom
Schedular
Schedular executes the task on a pool of carrier threads
● java.util.concurrent.Executor API exposes the Schedular
● Default schedular is a ForJoinPool
Source: Alan Bateman, Oracle „Project Loom Update” https://www.youtube.com/watch?v=NV46KFV1m-4

37. Project Loom
Fibers
● java.lang.Fibre currently supports:
– scheduling
– parking/unparking
– waiting for a fibre to terminate
● Fiber-friendly APIs
– java.util.concurrent locks
– java.net.Socket/ServerSocket
– java.nio.channels.SocketChannel and Pipes
– Thread.sleep
– JSSE implementation of TLS
Source: Alan Bateman, Oracle „Project Loom Update” https://www.youtube.com/watch?v=NV46KFV1m-4

38. Project Loom
Fibers Implementation
● Currently Thread and Fiber don’t have a common supertype
● Thread.currentThread() in context of Fibers
– Create adaptor (Shadow Thread)
– Adaptor emulates legacy Thread API (except deprecated methods like
stop, suspend and resume)
– Thread Local becomes Fiber Local
Source: Alan Bateman, Oracle „Project Loom Update” https://www.youtube.com/watch?v=NV46KFV1m-4

39. Project Loom
Structured Concurrency
Basic idea: Everytime that the control splits into multiple concurrent paths, we
want to guarantee that they join up again
try (var scope= FiberScope. open()) {
var fiber1= scope.schedule(task1);
var fiber2= scope.schedule(task2);
} //blocks until fiber1 and fiber2 terminate
Sources: Nathanial J. Smith „Notes on structured concurrency, or: Go statement considered harmful”
https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/
Roman Elizarov: “Structured concurrency with Coroutines in Kotlin” https://medium.com/@elizarov/structured-concurrency-
722d765aa952

40. Project Loom
Structured Concurrency
Cancelation:
● Each fiber has cancel status which can only be set once, which sets the
interrupt status and unparks the fiber
● The task can poll canceled status
try (var scope= FiberScope. open(PROPAGATE_CANCEL)) {
var fiber1= scope.schedule(task1);
var fiber2= scope.schedule(task2);
} //canceling the fiber executing this code will cancel fiber1 and fiber2
Source: Alan Bateman, Oracle „Project Loom Update” https://www.youtube.com/watch?v=NV46KFV1m-4

41. Project Loom
Current Status:
● Implemented initial prototype with Continuation and Fiber support
● Current prototype of Continuations and Fibers can run existing code
● Current focus on
– Performance improvement
– Stable Fiber API
– Debugger support
– Java Flight Recorder support
Source: Alan Bateman, Oracle „Project Loom Update” https://www.youtube.com/watch?v=NV46KFV1m-4

42. Project Loom
Limitations:
● Can‘t yield with native frames
● Can‘t yield while holding a monitor
Source: Alan Bateman, Oracle „Project Loom Update” https://www.youtube.com/watch?v=NV46KFV1m-4

43. Project Loom
Open Questions:
● Should the existing Thread API be completely re-examined?
● Can all existing code be run on top of Fibers?
Source: Alan Bateman, Oracle „Project Loom Update” https://www.youtube.com/watch?v=NV46KFV1m-4

44. Project Metropolis
Polyglot GraalVM for Java 8
Source: http://openjdk.java.net/projects/metropolis

45. Project Metropolis
Goals:
● High performance for all languages
● Zero overhead interoperability between languages
● Language-level virtualization level for shared tooling
Source: Oleg Selajev : “Run Code in Any Language Anywhere with GraalVM” https://www.youtube.com/watch?v=JoDOo4FyYMU

46. JEP 317
Experimental Java-Based JIT Compiler
Graal, a Java-based JIT compiler on the Linux/x64 platform, is the basis of the
experimental Ahead-of-Time (AOT) compiler introduced in JDK 9.
To Enable:
-XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler

48. GraalVM
Architecture
Sources: Practical Partial Evaluation for High-Performance Dynamic Language Runtimes
http://chrisseaton.com/rubytruffle/pldi17-truffle/pldi17-truffle.pdf
„The LLVM Compiler Infrastructure“ https://llvm.org/

49. GraalVM
Benchmarks
Sources: Renaissance Suite https://renaissance.dev/
Oleg Šelajev: “GraalVM for Java developers @ Spring I/O 2019” https://www.youtube.com/watch?v=GinNxS3OSi0

50. GraalVM
New in GraalVM 19 libgraal
Sources: „libgraal: GraalVM compiler as a precompiled GraalVM native image“ https://medium.com/graalvm/libgraal-
graalvm-compiler-as-a-precompiled-graalvm-native-image-26e354bee5c
Oleg Šelajev: “GraalVM for Java developers @ Spring I/O 2019” https://www.youtube.com/watch?v=GinNxS3OSi0
libgraal jargraal
• Libgraal is a shared library, produced by GraalVM Native Image, which contains a pre-compiled
version of the GraalVM compiler.
• In Java applications on GraalVM libgraal used as the top tier Just-In-Time compiler.
• libgraal improves startup times and completely avoids interfering with the heap usage and profiling
of the application code.

51. GraalVM
Architecture
Sources: Practical Partial Evaluation for High-Performance Dynamic Language Runtimes
http://chrisseaton.com/rubytruffle/pldi17-truffle/pldi17-truffle.pdf
„The LLVM Compiler Infrastructure“ https://llvm.org/

52. SubstrateVM
Source: Oleg Šelajev, Thomas Wuerthinger, Oracle: “Deep dive into using GraalVM for Java and JavaScript”
https://www.youtube.com/watch?v=a-XEZobXspo

53. GraalVM and SubstrateVM
Source: Oleg Selajev, Oracle : “Run Code in Any Language Anywhere with GraalVM” https://www.youtube.com/watch?v=JoDOo4FyYMU

54. Support of GraalVM native images at Spring Framework
Working toward GraalVM native image support without requiring additional
configuration or workaround is one of the themes of upcoming Spring
Framework 5.3
Source: „GraalVM native image support“ https://github.com/spring-projects/spring-framework/wiki/GraalVM-native-image-support

55. GraalVM on SubstrateVM
A game changer for Java & Serverless?
Cold Start :
Source: Ajay Nair „Become a Serverless Black Belt” https://www.youtube.com/watch?v=oQFORsso2go

56. AWS Lambda cold start time
by supported language
Source: Yan Cui: https://read.acloud.guru/does-coding-language-memory-or-package-size-affect-cold-starts-of-aws-lambda-a15e26d12c76

57. GraalVM on SubstrateVM
A game changer for Java & Serverless?
Java Function compiled into a native executable using GraalVM on
SubstrateVM reduces
● “cold start” times
● memory footprint
● your bill in the cloud
by order of magnitude compared to running on JVM.

58. Lambda Layers
& Lambda
Runtime API
Door opener for using
• Newest Java versions
• Other JVM languages
Source: Mathias Düsterhöft : “Fighting cold startup issues for your Kotlin Lambda with GraalVM”
https://github.com/mduesterhoeft/kotlin-graalvm-custom-aws-lambda-runtime-talk

59. Quarkus
● Quarkus is a Kubernetes Native Java framework developed by Red Hat
tailored for GraalVM and HotSpot, crafted from best-of-breed Java libraries
and standards.
● The goal of Quarkus is
– make Java a leading platform in Kubernetes and serverless environments
– offering developers a unified reactive and imperative programming model
– optimally address a wider range of distributed application architectures.
Source: Jason Greene: „Introducing Quarkus: a next-generation Kubernetes native Java framework”
https://developers.redhat.com/blog/2019/03/07/quarkus-next-generation-kubernetes-native-java-framework/

60. is still an interesting and great
programming language

62. www.iplabs.de
Thank You!