Upgrade to Pro — share decks privately, control downloads, hide ads and more …

From Java 11 to 17: only the best of breed

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.

Elder Moraes

May 13, 2022

More Decks by Elder Moraes

Other Decks in Technology


  1. From Java 11 to 17: only the best of breed

    Elder Moraes Developer Advocate @elderjava
  2. @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
  3. @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
  4. @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
  5. @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
  6. @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
  7. @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
  8. @elderjava 14 JEP 320 Remove the Java EE and CORBA

    Modules https://openjdk.java.net/jeps/320
  9. @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???
  10. @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)
  11. @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"
  12. @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
  13. @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
  14. @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
  15. @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
  16. @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
  17. @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
  18. @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
  19. @elderjava 28 $ jcmd <pid> JFR.start $ jcmd <pid> JFR.dump

    filename=recording.jfr $ jcmd <pid> JFR.stop Or using jcmd JEP 328: Flight Recorder
  20. @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
  21. @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
  22. @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
  23. @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
  24. @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
  25. @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
  26. @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
  27. @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
  28. @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
  29. @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)
  30. @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
  31. @elderjava 45 JEP 410 Remove the Experimental AOT and JIT

    Compiler https://openjdk.java.net/jeps/410
  32. @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
  33. @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…
  34. @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…