We all know that Java's release cycle now is 6 months. The Java 12 has been released in March 2019, with the next version, Java 13, to come in September 2019. This session is to introduce new features and functions in Java 12 and 13. Also, we will mention other relevant features released in the previous Java versions. https://cyberjos.blog/java/seminar/oracle-groundbreakers-2019-taiwan-whats-new-in-last-java-versions/

1. What’s New in
Last Java Versions

2. About Me
u Majored in Applied Mathematics
u Cloud Technical Lead, Asia @ Ayla Networks (艾拉物聯)
u 21 years experience on Java, 25 years on programming
u Experience on Basic, C/C++, LPC, JavaScript, Python…
u JCConf 2014, 2016, 2017, 2018 speaker, TWJUG member
u 擔任過電腦資訊講師，並曾在加值簡訊服務商、遊戲雲端平台、全
球電⼦商務平台、資訊安全防護、使⽤者⾏為管理等公司中任職
u 負責程式撰寫、軟體設計、架構規劃及技術教學，並參與各式專案
設計、架構、開發、實作、測試、除錯、調效與維護
u 希望能⼀輩⼦玩技術寫程式到⽼

3. Agenda
u Version Changes
u JVM / Tools
u Class-Data Sharing (CDS)
u Garbage Collector
u Security
u I18N
u New APIs
u Syntax Sugar

4. Version Changes

5. Release Dates
u Java 8: 2014-03-18
u Java 9: 2017-09-21
u Java 10: 2018-03-20
u Java 11: 2018-09-25 (LTS)
u Java 12: 2019-03-19
u Java 13: 2019-09-17
u Java 14: 2020-03-17
u Java 15: 2020-09-xx
u Java 16: 2021-03-xx
u Java 17: 2021-09-xx (LTS)

6. Release Dates (Number of JEPs)
u Java 8: 2014-03-18 (55)
u Java 9: 2017-09-21 (91)
u Java 10: 2018-03-20 (12)
u Java 11: 2018-09-25 (17)
u Java 12: 2019-03-19 (8)
u Java 13: 2019-09-17 (5)
u Java 14: 2020-03-17 (3 - planning)

7. JVM / Tools

8. JVM / Tools
u 9 - JEP 243: Java-Level JVM Compiler Interface
u 10 – JEP 317: Experimental Java-Based JIT Compiler
u 11 – JEP 181: Nest-Based Access Control
u 11 – JEP 309: Dynamic Class-File Constants
u 11 – JEP 315: Improve AArch64 Intrinsics
u 11 – JEP 330: Launch Single-File Source-Code Programs
u 11 – JEP 331: Low-Overhead Heap Profiling
u 12 – JEP 230: Microbenchmark Suite
u 12 – JEP 340: One AArch64 Port, Not Two
u 14 – JEP 358: Helpful NullPointerExceptions

9. Experimental Java-Based JIT Compiler (Graal)
u Enable Graal to be used as an experimental JIT compiler,
starting with the Linux/x64 platform. Graal will use the
JVM compiler interface (JVMCI) introduced in JDK 9. Graal is
already in the JDK, so enabling it as an experimental JIT will
primarily be a testing and debugging effort
u To enable Graal as the JIT compiler, use the following
options on the java command line:
-XX:+UnlockExperimentalVMOptions
-XX:+UseJVMCICompiler

10. Launch Single-File Source-Code Programs

11. Helpful NullPointerExceptions
u It’s very hard to troubleshooting the root cause now when
the following statements throw NullPointerExceptions:
u a.b.c.i = 99
u a[i][j][k] = 99
u a.i = b.j

12. Helpful NullPointerExceptions
u a.b.c.i = 99
u Exception in thread "main" java.lang.NullPointerException:
Cannot read field "c" because "a.b" is null
at Prog.main(Prog.java:5)
u a[i][j][k] = 99
u Exception in thread "main" java.lang.NullPointerException:
Cannot load from object array because "a[i][j]" is null
at Prog.main(Prog.java:5)
u a.i = b.j
u Exception in thread "main" java.lang.NullPointerException:
Cannot read field "j" because "b" is null
at Prog.main(Prog.java:5)

13. Class-Data Sharing (CDS)

14. Class-Data Sharing
u 5 - Class Data Sharing (CDS)
u 9 - JEP 250: Store Interned Strings in CDS Archives
u 10 – JEP 310: Application Class-Data Sharing
u 11 - Make -Xshare:auto the default for server VM
u 12 – JEP 341: Default CDS Archives
u 13 – JEP 350: Dynamic CDS Archives

15. Class-Data Sharing
u Class Data Sharing is intended to remove the fixed cost of
loading core classes at startup. It also allows some cached
files to be shared between JVMs which helps if you’re
running a lot of them, even if the JVMs are containerized.
u It only allows bootstrap class loader to load archived
system classes with serial garbage collector

16. Store Interned Strings in CDS Archives
u Reduce memory consumption by sharing the String objects and
underlying char array objects amongst different JVM processes
u Only support shared strings for the G1 GC. Shared strings
require a pinned region, and G1 is the only HotSpot GC that
supports pinning
u Only support 64-bit platforms with compressed object and class
pointers

17. Application Class-Data Sharing
u Application CDS extends CDS to allow the built-in system
class loader (a.k.a., the "app class loader"), the built-in
platform class loader, and custom class loaders to load
archived application classes with G1 garbage collector.
u java -Xshare:off -XX:+UseAppCDS
-XX:DumpLoadedClassList=x.lst -cp x.jar HelloWorld
java -Xshare:dump -XX:+UseAppCDS
-XX:SharedClassListFile=x.lst
-XX:SharedArchiveFile=x.jsa -cp x.jar
java -Xshare:on -XX:+UseAppCDS
-XX:SharedArchiveFile=x.jsa -cp x.jar HelloWorld

18. Default CDS Archives
u Enhance the JDK build process to generate a class data-sharing
(CDS) archive by default if not exist, using the default class list,
on 64-bit platforms.
u java -Xshare:dump
java -Xshare:on -cp x.jar HelloWorld

19. Default CDS Archives

20. Dynamic CDS Archives
u Extend AppCDS to allow the dynamic archiving of classes at the
end of Java application execution. The archived classes will
include all loaded application classes and library classes that
are not present in the default, base-layer CDS archive, without
doing one or more trial runs.
u Default CDS archive (+ dynamic archive)
u java -XX:ArchiveClassesAtExit=x.jsa -cp x.jar HelloWorld
java -XX:SharedArchiveFile=x.jsa -cp x.jar HelloWorld

21. Garbage Collector

22. Garbage Collector
u 9 – JEP 248: Make G1 the Default Garbage Collector
u 10 – JEP 304: Garbage-Collector Interface
u 11 – JEP 318: Epsilon: A No-Op Garbage Collector
u 11 – JEP 333: ZGC: A Scalable Low-Latency Garbage
Collector (Experimental)
u 12 – JEP 189: Shenandoah: A Low-Pause-Time Garbage
Collector (Experimental)
u 12 – JEP 344: Abortable Mixed Collections for G1
u 12 – JEP 346: Promptly Return Unused Committed Memory
from G1
u 13 – JEP 351: ZGC: Uncommit Unused Memory

23. Parallel Full GC for G1
u The G1 garbage collector is designed to avoid full
collections, but when the concurrent collections can't
reclaim memory fast enough a fall back full GC will occur.
u The implementation of the full GC for G1 uses a single
threaded mark-sweep-compact algorithm. We intend to
parallelize it and use the same number of threads as the
Young and Mixed collections do.

24. Abortable Mixed Collections for G1
u One goal of G1 is to meet a user supplied pause time target for
its collection pauses. G1 uses an engine to select the amount of
work to be done during a collection. The result of this selection
is a set of regions called the collection set.
u Once the collection has been started then G1 must collect all
live objects in all regions of the collection set without stopping,
which may exceed the pause time goal.
u Now G1 split the collection set into two parts, a mandatory
and an optional part. After G1 finishes collecting the mandatory
part, G1 starts collecting the optional part at a much more
granular level, if there is time left.

25. Promptly Return Unused Committed Memory from G1
u Enhance the G1 garbage collector to automatically return Java
heap memory to the operating system when idle.
u Currently the G1 only returns memory from the Java heap at
either a full GC or during a concurrent cycle, but G1 tries hard
to completely avoid full GCs, and only triggers a concurrent
cycle based on Java heap occupancy and allocation activity.
u G1 will, during inactivity of the application, periodically try to
continue or trigger a concurrent cycle to determine overall Java
heap usage. This will cause it to automatically return unused
portions of the Java heap back to the operating system.
Optionally, under user control, a full GC can be performed to
maximize the amount of memory returned.

26. Promptly Return Unused Committed Memory from G1
u The application is considered inactive, and G1 triggers a
periodic garbage collection if both:
uMore than G1PeriodicGCInterval milliseconds have passed
since any previous garbage collection pause and there is no
concurrent cycle in progress at this point. A value of zero
indicates that periodic garbage collections to promptly
reclaim memory are disabled.
uThe average one-minute system load value as returned by the
getloadavg() call on the JVM host system (e.g. container) is
below G1PeriodicGCSystemLoadThreshold. This condition
is ignored if G1PeriodicGCSystemLoadThreshold is zero.

27. Z Garbage Collector
u It supports TB-level GC with very low pause time (<10ms),
developed by Oracle.
u By convention, experimental features in the JVM are disabled
by default by the build system. ZGC, being an experimental
feature, will therefore not be present in a JDK build unless
explicitly enabled at compile-time using the configure option:
u --with-jvm-features=zgc
u To enable/use ZGC, the following JVM options will therefore be
needed:
u -XX:+UnlockExperimentalVMOptions
-XX:+UseZGC

28. Shenandoah Garbage Collector
u It is a low-pause-time garbage collector from Red Hat, and
supports AArch64 and Amd64 architecture. It is also low-
pause-time. Unlike ZGC based on colored pointers,
Shenandoah GC uses brooks pointers.
u To enable it by using the following during building first:
u --with-jvm-features=“-shenandoahgc”
u Then use the following JVM options to enable:
u -XX:+UnlockExperimentalVMOptions
-XX:+UseShenandoahGC

29. ZGC Uncommit Unused Memory
u ZGC was enhanced to return unused heap memory to the
operating system. This is useful for applications and
environments where memory footprint is a concern
u This feature is enabled by default, but can be explicitly
disabled using -XX:-ZUncommit

30. Security

31. Security
u 11 – JEP 324: Key Agreement with Curve25519 and
Curve448
u 11 – JEP 329: ChaCha20 and Poly1305 Cryptographic
Algorithms
u 11 - JEP 332: Transport Layer Security (TLS) 1.3
u 12 - ChaCha20 and Poly1305 TLS Cipher Suites

32. ChaCha20 and Poly1305 Cipher Suite
u TLS 1.2
uTLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
uTLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
uTLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
u TLS 1.3
uTLS_CHACHA20_POLY1305_SHA256

33. I18N

34. I18N
u 8 - JEP 133: Unicode 6.2
u 9 – JEP 226: UTF-8 Property Resource Bundles
u 9 - JEP 227: Unicode 7.0
u 9 - JEP 267: Unicode 8.0
u 10 - JEP 314: Additional Unicode Language-Tag Extensions
u 11 - JEP 327: Unicode 10
u 12 – Unicode 11
u 12 - Square Character Support for Japanese New Era
u 13 – Unicode 12.1

35. UTF-8 Property Resource Bundles
u In Java SE 9, properties files are loaded in UTF-8 encoding. In
previous releases, ISO-8859-1 encoding was used for loading
property resource bundles.
u Most existing properties files should not be affected: UTF-8 and
ISO-8859-1 have the same encoding for ASCII characters, and
human-readable non-ASCII ISO-8859-1 encoding is not valid UTF-
8. If an invalid UTF-8 byte sequence is detected, the Java
runtime automatically rereads the file in ISO-8859-1.
u java.util.PropertyResourceBundle.encoding=ISO-8859-1

36. New Japanese New Era

37. New APIs

38. New APIs
u 11 – JEP 321: HTTP Client (Standard)
u 11 - JEP 328: Flight Recorder
u 11 - New APIs in String
u 12 - JEP 334: JVM Constants API
u 12 - Support for Compact Number Formatting
u 13 – JEP 353: Reimplement the Legacy Socket API
u 14 - JEP 349: JFR Event Streaming
u 14 – JEP 352: Non-Volatile Mapped Byte Buffers

39. Deprecated APIs
u 11 – JEP 320: Remove the Java EE and CORBA Modules
u 11 - JEP 335: Deprecate the Nashorn JavaScript Engine
u 11 - JEP 336: Deprecate the Pack200 Tools and API

40. HTTP Client

41. Flight Recorder – Goals
u Provide a low-overhead data collection framework for
troubleshooting Java applications and JVM.
uProvide APIs for producing and consuming data as events
uProvide a buffer mechanism and a binary data format
uAllow the configuration and filtering of events
uProvide events for the OS, the JVM, and the JDK libraries
u No measurable performance overhead when not enabled

42. Flight Recorder
u Modules: jdk.jfr, jdk.management.jfr
u Command: java -XX:StartFlightRecording ...
u Recordings may also be started and controlled using the
bin/jcmd tool:
u $ jcmd <pid> JFR.start
u $ jcmd <pid> JFR.dump filename=recording.jfr
u $ jcmd <pid> JFR.stop

43. New API in String

44. Support for Compact Number Formatting

45. Reimplement the Legacy Socket API
u The underlying implementations of java.net.Socket and
java.net.ServerSocket have been reimplemented. The
original used PlainSocketImpl from JDK1.0. Now they uses
NioSocketImpl
u Adding -Djdk.net.usePlainSocketImpl in JVM options can let
you use the old version of Socket API.

46. Syntax Sugar

47. Syntax Sugar
u 10 - JEP 286: Local-Variable Type Inference
u 11 - JEP 323: Local-Variable Syntax for Lambda Parameters
u 12 - JEP 325: Switch Expressions (Preview)
u 12 - JEP 326: Raw String Literals (Preview)
u 13 - JEP 354: Switch Expressions (Preview)
u 13 - JEP 355: Text Blocks (Preview)

48. Local-Variable Type Inference

49. Local-Variable Syntax for Lambda Parameters

50. Switch Expressions

51. Switch Expressions – Assignment

52. Switch Expressions – Spec

53. Switch Expressions in Java 12 (break)

54. Switch Expressions in Java 13 (yield)

55. Text Blocks

56. Text Blocks – Parameter

57. Text Blocks – New Line Difference

58. Text Blocks – Escape Character

59. Text Blocks - Indents

60. Thank you!