Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

@elderjava 2 Premises

Slide 3

Slide 3 text

@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

Slide 4

Slide 4 text

@elderjava 4 Metholodoly

Slide 5

Slide 5 text

@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

Slide 6

Slide 6 text

@elderjava 6 Methodology

Slide 7

Slide 7 text

@elderjava 7 Methodology

Slide 8

Slide 8 text

@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

Slide 9

Slide 9 text

@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

Slide 10

Slide 10 text

@elderjava 10 Who is it for

Slide 11

Slide 11 text

@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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

@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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

@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

Slide 20

Slide 20 text

@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

Slide 21

Slide 21 text

@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

Slide 22

Slide 22 text

@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

Slide 23

Slide 23 text

@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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

@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

Slide 26

Slide 26 text

@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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

@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

Slide 30

Slide 30 text

@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

Slide 31

Slide 31 text

@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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

@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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

@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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

@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

Slide 38

Slide 38 text

@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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

@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

Slide 41

Slide 41 text

@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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

@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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

@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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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