From Java 11 to 17: only the best of breed Elder Moraes Developer Advocate @elderjava

@elderjava 2 Premises

@elderjava 3 1. The approach will be from a enterprise developer’s point of view 2. Therefore only LTS (11 e 17) versions will be considered 3. Won’t talk about 18? No, it’s not LTS… 4. All comparisons will be towards Java 8 (if using older versions, please upgrade) 5. Won’t cover features that are: • Preview: might change • Experimental: only 25% done • Incubator: seems like Experimental, but with a different distribution method • Deprecate: prepare to stop using it • Removal: hope you did your homework Premises

@elderjava 4 Metholodoly

@elderjava 5 1. There are 16 features on JDK 11 and 13 on JDK 17… 29 total 2. But we only have a few minutes, not a few hours 3. So, based on the “enterprise developer” premise, will only cover what is really interesting to an enterprise developer 4. Each feature is identified as: • S: for “sure” (worthy of learning) • N: for “nope” (only if you are curious) • C: for “comment" (#tips) Methodoly

@elderjava 6 Methodology

@elderjava 7 Methodology

@elderjava 8 Methodology • Sure • 321: HTTP Client (Standard) • 328: Flight Recorder • 330: Launch Single-File Source-Code Programs • 332: Transport Layer Security (TLS) 1.3 • 356: Enhanced Pseudo-Random Number Generators • 403: Strongly Encapsulate JDK Internals

@elderjava 9 Metodologia • #tips • 318: Epsilon: A No-Op Garbage Collector • 320: Remove the Java EE and CORBA Modules • 409: Sealed Classes • 410: Remove the Experimental AOT and JIT Compiler • 411: Deprecate the Security Manager for Removal

@elderjava 10 Who is it for

@elderjava 11 1. For whom was looking for a studying roadmap that is simple, practical and straight to the point 2. For whom was looking arguments to persuade someone that upgrade the Java version is something good for the project and for the business Who is it for

@elderjava 12 JEP 318 Epsilon: A No-Op Garbage Collector https://openjdk.java.net/jeps/318

@elderjava 13 JEP 318: Epsilon: A No-Op Garbage Collector • Probably the GC with the smallest possible overhead • Context: to do its job, the GC uses some processing, which might penalize JVM performance in general • It manages memory allocation, but not memory release • In other words, when heap space is over, the JVM stops working • “Wait, what? A garbage collector that doesn’t collect the garbage?” • Performance tests • Memory tests • JVM interface tests • Jobs with an extremely short life cycle • Fine-tuning for latency • Fine-tuning for throughput

@elderjava 14 JEP 320 Remove the Java EE and CORBA Modules https://openjdk.java.net/jeps/320

@elderjava 15 JEP 320: Remove the Java EE and CORBA Modules • They are Deprecated since Java 9 • So, if you are using JDK 11 and still use them… well, you are not getting them from the JDK anymore • If you need some Java EE module, just migrate to Jakarta EE • If you use some CORBA module… do you still use CORBA???

@elderjava 16 JEP 321 HTTP Client (Standard) https://openjdk.java.net/jeps/321

@elderjava 17 JEP 321: HTTP Client (Standard) • The HTTP Client API started as an Incubator in the JDK 9, was updated in the JDK 10, and was officially released in the JDK 11 • The main target is to provide a better option when compared to the URLConnection API that: • It’s based on some obsolete protocols (like ftp and gopher) • It’s older than HTTP/1.1 • It’s hard to use, hard to maintain, and poorly documented • Only works in blocking mode (one single thread for each request/response)

@elderjava 18 JEP 321: HTTP Client (Standard) • The new API uses CompletableFutures to manage requests and responses in a non-blocking approach • The flow control and backpressure are done using the java.util.concurrent.Flow (reactive-streams.org) API "But Elder, what is backpressure?” Learn more here: "Backpressure explained - the resisted flow of data through software"

@elderjava 19 JEP 321: HTTP Client (Standard) • The new API is: • Easier to use • Easier to maintain • More traceable • More usage possibilities both with HTTP/1.1 and HTTP/2 • Both package and module are named java.net.http

@elderjava 20 JEP 321: HTTP Client (Standard) HttpClient client = HttpClient.newBuilder() .version(Version.HTTP_2) .followRedirects(Redirect.SAME_PROTOCOL) .proxy(ProxySelector.of(new InetSocketAddress("www-proxy.com", 8080))) .authenticator(Authenticator.getDefault()) .build(); Creating a client instance

@elderjava 21 JEP 321: HTTP Client (Standard) HttpRequest request = HttpRequest.newBuilder() .uri(URI.create("http://openjdk.java.net/")) .timeout(Duration.ofMinutes(1)) .header("Content-Type", "application/json") .POST(BodyPublishers.ofFile(Paths.get("file.json"))) .build() Creating a request

@elderjava 22 JEP 321: HTTP Client (Standard) HttpResponse response = client.send(request, BodyHandlers.ofString()); System.out.println(response.statusCode()); System.out.println(response.body()); Getting a sync response

@elderjava 23 JEP 321: HTTP Client (Standard) client.sendAsync(request, BodyHandlers.ofString()) .thenApply(response -> { System.out.println(response.statusCode()); return response; } ) .thenApply(HttpResponse::body) .thenAccept(System.out::println); Getting a async response

@elderjava 24 JEP 328 Flight Recorder https://openjdk.java.net/jeps/328

@elderjava 25 JEP 328: Flight Recorder • It’s a low overhead data collector framework (less than 1% of performance impact) • Useful for both applications troubleshooting and JVM troubleshooting • What it does: • Provides APIs for producing and consuming data as events • Allow events configuration and filters • Provides events for OS, Hotspot, and JDK libraries • What it doesn’t do: • It doesn’t provide data visualization and analysis • It doesn’t enable data collection by default • All events registered are recorded in a file that allows after-the-fact analysis

@elderjava 26 JEP 328: Flight Recorder • The JFR (Java Flight Recorder) extends JEP 167 capabilities (Event-Based JVM Tracing), which creates only Hotspot events • The JEP 167 also has a primitive backend that gets the data generated from the events and sends them to the stdout • The JFR replaces this backend with another one with higher performance both for Java and Hotspot

@elderjava 27 $ java -XX:StartFlightRecording ... How to start the JFR JEP 328: Flight Recorder

@elderjava 28 $ jcmd JFR.start $ jcmd JFR.dump filename=recording.jfr $ jcmd JFR.stop Or using jcmd JEP 328: Flight Recorder

@elderjava 29 import jdk.jfr.*; @Label("Hello World") @Description("Helps the programmer getting started") class HelloWorld extends Event { @Label("Message") String message; } Creating events (extends Event) JEP 328: Flight Recorder

@elderjava 30 public static void main(String... args) throws IOException { HelloWorld event = new HelloWorld(); event.message = "hello, world!"; event.commit(); } Creating events (commit) JEP 328: Flight Recorder

@elderjava 31 import java.nio.file.*; import jdk.jfr.consumer.*; Path p = Paths.get("recording.jfr"); for (RecordedEvent e : RecordingFile.readAllEvents(p)) { System.out.println(e.getStartTime() + " : " + e.getValue("message")); } Extracting the events data file JEP 328: Flight Recorder

@elderjava 32 JEP 330 Launch Single-File Source- Code Programs https://openjdk.java.net/jeps/330

@elderjava 33 JEP 330: Launch Single-File Source-Code Programs • Make the java launcher capable of running a Java application that contains only one single .java file • It’s a usual situation in the first stages of the language learning, as well as when writing small utility programs • In these cases, accordingly to the specification, have to compile before running is “pure ceremony" • In other words, the JEP 330 make possible to do something like this: $ java HelloWorld.java

@elderjava 34 JEP 332 Transport Layer Security (TLS) 1.3 https://openjdk.java.net/jeps/332

@elderjava 35 JEP 332: Transport Layer Security (TLS) 1.3 • That’s a straight-to-the-point feature… • Its purpose is to implement the TLS 1.3 accordingly to the RFC 8446 (Request for Comments of IETF- Internet Engineering Task Force) • Version 1.3 brings a huge review in terms of security and performance • The JDK Java Security Socket Extension (JSSE) already provides the framework and the Java implementation for the TLS, SSL, and DTLS

@elderjava 36 JEP 356 Enhanced Pseudo-Random Number Generators https://openjdk.java.net/jeps/356

@elderjava 37 JEP 356: Enhanced Pseudo-Random Number Generators • A “Pseudo-Random Number” is a “almost random” number… it’s not completely random because it’s based on a starting number known as seed (and this one can be really random) • Pseudo-Random Number Generators = PRNGs • This JEP: • Make it easier to use a number of different PRNGs algorithms • Improves the streams support • Keep the java.util.Random behavior • Brings a new interface, a RandomGenerator, that provides a single API for both the new and the old PRNGs • The RandomGenerator is created by the RandomGeneratorFactory class

@elderjava 38 //old style RandomGenerator rg1 = new Random(42); //new style RandomGenerator rg2 = RandomGeneratorFactory.of("Random").create(42); //calling a new generator RandomGenerator rg3 = RandomGeneratorFactory.of("L32X64MixRandom").create(42); Example JEP 356: Enhanced Pseudo-Random Number Generators

@elderjava 39 JEP 403 Strongly Encapsulate JDK Internals https://openjdk.java.net/jeps/403

@elderjava 40 JEP 403: Strongly Encapsulate JDK Internals • This JEP is part of the famous Project Jigsaw (and no, it wasn’t only about modules) • Its main purpose is to discourage the usage of the JDK internals • Since the JDK 9 and until JDK 16 it was using the “relaxed strong encapsulation” as standard, which means that it was still possible to access all internals that was available since JDK 8 (mainly for migration reasons) • Starting with JDK 17, they switched to the “strong encapsulation” standard, where all non-public elements from exported packages are unavailable, and all elements from non-exported packages are unavailable as well • This change aims to improve both the maintainability and security • For example, some internal elements have the privilege to define a class in a specific class loader, or even to access sensitive data like cryptography keys

@elderjava 41 JEP 403: Strongly Encapsulate JDK Internals • The encapsulation is done by using the“—illegal-access" flag • --illegal-access=permit: allows access to all internal packages that exist in the JDK 8 • --illegal-access=warn: like the previous one, but gives a warning on each illegal access • --illegal-access=debug: just like warn, but also throws a stack trace • --illegal-access=deny: disable all illegal access • The deny mode is the default since JDK 17 • 457 internal packages were affected by this change, accordingly to this list: https://cr.openjdk.java.net/~mr/jigsaw/jdk8-packages-denied-by-default

@elderjava 42 JEP 409 Sealed Classes https://openjdk.java.net/jeps/409

@elderjava 43 JEP 409: Sealed Classes • Interfaces and classes using the Sealed type restrict which classes or interfaces can extend or implement them • Provides a more declarative way to restrict the usage of a superclass if compared to the access modifiers • It’s a big ally to the implementation of the pattern matching (Project Amber - https://openjdk.java.net/projects/amber/design-notes/patterns/pattern- matching-for-java) • Has a lot of possibilities of usage when building frameworks, for example (where this kind of restriction is most common)

@elderjava 44 package com.example.geometry; public abstract sealed class Shape permits com.example.polar.Circle, com.example.quad.Rectangle, com.example.quad.simple.Square { ... } Example JEP 409: Sealed Classes

@elderjava 45 JEP 410 Remove the Experimental AOT and JIT Compiler https://openjdk.java.net/jeps/410

@elderjava 46 JEP 410: Remove the Experimental AOT and JIT Compiler • This compiler was available since the JDK 10 and could be accessed by using a flag • It’s the same JIT Compiler used by Graal VM • It was removed in the JDK 16 and no one complained! • It will not be part of the Open JDK anymore, but will keep evolving through Graal VM project

@elderjava 47 JEP 411 Deprecate the Security Manager for Removal https://openjdk.java.net/jeps/411

@elderjava 48 JEP 411: Deprecate the Security Manager for Removal • Well, if you use the Security Manager for something… prepare to ditch it • It’s available since JDK 1.0 • Although its name, it’s not that secure…

@elderjava 49 1. A study roadmap 2.A list of reasons to encourage the usage of the latest LTS in your project Now with this features list you have…

@elderjava 50 Meet the Developer Sanbox for OpenShift dn.dev/devnation-sandbox