From Java 11 to 17: only the best of breed

What do you think about Java's 6-month release cycle?
It isn't just a matter of time between versions, but also the number of new features on each one of them. It was ninety one in Java 9, and now only fourteen in Java 17. In other words, instead of waiting years to get and learn dozens of new features, you only need six months to do it with a handful of them.
So what about having the right path to get the best of each Java LTS version, covering both 11 and 17? That's what this talk will show you.
Come and join us to learn not only the best parts of the latest Java versions but also the best way to use them in your projects.

Transcript

1. From Java 11 to 17: only the best of breed Elder Moraes Developer Advocate @elderjava
2. @elderjava 2 Premises
3. @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
4. @elderjava 4 Metholodoly
5. @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
6. @elderjava 6 Methodology
7. @elderjava 7 Methodology
8. @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
9. @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
10. @elderjava 10 Who is it for
11. @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
12. @elderjava 12 JEP 318 Epsilon: A No-Op Garbage Collector https://openjdk.java.net/jeps/318
13. @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
14. @elderjava 14 JEP 320 Remove the Java EE and CORBA Modules https://openjdk.java.net/jeps/320
15. @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???
16. @elderjava 16 JEP 321 HTTP Client (Standard) https://openjdk.java.net/jeps/321
17. @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)
18. @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"
19. @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
20. @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
21. @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
22. @elderjava 22 JEP 321: HTTP Client (Standard) HttpResponse<String> response = client.send(request, BodyHandlers.ofString()); System.out.println(response.statusCode()); System.out.println(response.body()); Getting a sync response
23. @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
24. @elderjava 24 JEP 328 Flight Recorder https://openjdk.java.net/jeps/328
25. @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
26. @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
27. @elderjava 27 $ java -XX:StartFlightRecording ... How to start the JFR JEP 328: Flight Recorder
28. @elderjava 28 $ jcmd <pid> JFR.start $ jcmd <pid> JFR.dump filename=recording.jfr $ jcmd <pid> JFR.stop Or using jcmd JEP 328: Flight Recorder
29. @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
30. @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
31. @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
32. @elderjava 32 JEP 330 Launch Single-File Source- Code Programs https://openjdk.java.net/jeps/330
33. @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
34. @elderjava 34 JEP 332 Transport Layer Security (TLS) 1.3 https://openjdk.java.net/jeps/332
35. @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
36. @elderjava 36 JEP 356 Enhanced Pseudo-Random Number Generators https://openjdk.java.net/jeps/356
37. @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
38. @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
39. @elderjava 39 JEP 403 Strongly Encapsulate JDK Internals https://openjdk.java.net/jeps/403
40. @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
41. @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
42. @elderjava 42 JEP 409 Sealed Classes https://openjdk.java.net/jeps/409
43. @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)
44. @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
45. @elderjava 45 JEP 410 Remove the Experimental AOT and JIT Compiler https://openjdk.java.net/jeps/410
46. @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
47. @elderjava 47 JEP 411 Deprecate the Security Manager for Removal https://openjdk.java.net/jeps/411
48. @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…
49. @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…
50. @elderjava 50 Meet the Developer Sanbox for OpenShift dn.dev/devnation-sandbox