The Cool Thing about Cool Things in Java

16 & 17 LTS 😉

Highlights of the latest upgrade of standard Java include primitive classes, sealed classes, records, a vector API, and ports for Windows on ARM64 and Alpine Linux.

@_tamanm

|

Mohamed Taman

Chief Solutions Architect

Publications

-> From the vector API to records to elastic metaspace, there’s a lot packed into Java 16.

-> Even more greatness packed into Java 16, including tools for improving future JVMs.

You can catch me (🤝)

Here 👇

Or by googling 🕵 me

"Mohamed Taman"

Agenda

@_tamanm

|

Explore new Language Features.

➥

Explore the new & Improved language APIs.

➥

Farewell to APIs has gone forever.

➥

Learn about new Tools & JVM.

➥

Check out Java's Important Features.

➥

@_tamanm

|

What is the Relation between JDK 16 and 17 LTS?

JDK 16 is a feature release backed by just six months of support from Oracle.

JDK 17, due in September, will be a long-term support (LTS) release.

Oracle frames JDK16 as a starting point for migration to JDK 17, with users able to test on JDK 16 before deploying to JDK17.

- LTS releases are published every two years.

Agenda

Check out Java's important features!

Explore new Language Features.

Explore the new & Improved language APIs.

Farewell to APIs has gone forever.

Learn about new Tools & JVM.

➥

@_tamanm

|

Check out Java's important features!

features that made java sexier 🥷

@_tamanm

|

What behind features like

Preview Feature.
Incubator Modules.
Deprecation.
Features Marked for Removals.

@_tamanm

|

@_tamanm

|

JEP 12: Preview Features

Since JDK 12

Go to JEP 12

A preview feature is:

A new feature of the Java language ("preview language feature"), or

A new module, package, class, interface, method, constructor, field, or enum constant in the java.* or javax.* namespace ("preview API").

A new feature of the JVM ("preview VM feature"), or

whose design, specification, and implementation are complete, but which would benefit from a period of broad exposure and evaluation before either achieving final and permanent status in the Java SE Platform or else being refined or removed.

@_tamanm

|

mohamed_taman:~$ jshell --enable-preview

mohamed_taman -- -bash

Enabling preview features during development.

When using Jshell:

When using maven:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>${maven-compiler-plugin.version}</version>
    <configuration>
        <release>${java.version}</release>
        <compilerArgs>
            <arg>--enable-preview</arg>
        </compilerArgs>
        ...
    </configuration>
</plugin>

mohamed_taman -- -bash

When using IDE:

@_tamanm

|

JEP 11: Incubator Modules

Since JDK 9

Go to JEP 11

An incubating feature is:

An API or a tool of a non-trivial size that is under development for eventual inclusion in the Java SE Platform or the JDK.

The API or tool is not yet sufficiently proven, so it is desirable to defer standardization or finalization for a small number of feature releases to gain additional experience and feedback.

An incubator module: is a module in a JDK Release Project that offers an incubating feature. And is identified by the jdk.incubator—prefix in its module name.

For example, the HTTP & WebSocket client module is introduced in Java 9 under incubator module jdk.incubator.httpclient, and in Java 11, it goes to production under module java.net.http.

@_tamanm

|

JEP 277: Enhanced Deprecation

Since JDK 9

Go to JEP 277

Revamp the @Deprecated annotation, and provide tools to strengthen the API life cycle.

Provide better information about the status and intended disposition of APIs in the specification.

Provide a tool to analyze an application's static usage of deprecated APIs. By adding two methods to the java.lang.Deprecated annotation, forRemoval() returning boolean, and since() returning String.

Agenda

Check out Java's important features!

Explore new Language Features.

Explore the new & Improved language APIs.

Farewell to APIs has gone forever.

Learn about new Tools & JVM.

✓

➥

@_tamanm

|

Explore new Language Features

Java SE features that made java more concise and less verbose. 🦾

@_tamanm

|

@_tamanm

|

JEP 395: Records

1st Prev JDK 14

Go to JEP 395

Final JDK 16

2nd Prev JDK 15

It is a common complaint that "Java is too verbose" or has "too much ceremony." Some of the worst offenders are classes that are nothing more than immutable data carriers for a handful of values.

Properly writing such a data-carrier class involves a lot of low-value, repetitive, error-prone code: constructors, accessors, equals, hashCode, toString, etc.

class Point {
    private final int x;
    private final int y;

    Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

    int x() { return x; }
    int y() { return y; }

    public boolean equals(Object o) {
        if (!(o instanceof Point)) return false;
        Point other = (Point) o;
        return other.x == x && other.y == y;
    }

    public int hashCode() {
        return Objects.hash(x, y);
    }

    public String toString() {
        return String.format("Point[x=%d, y=%d]", x, y);
    }
}

For example, a class Point to carry x and y coordinates inevitably ends up like this:

@_tamanm

|

JEP 395: Records

record Point(int x, int y) { }

Providing records classes that act as transparent carriers for immutable data. Records can be considered nominal tuples.

By reducing the ceremony of Java by cutting boilerplate code. So the Point class could be re-written as:

Constructors for record classes

Canonical Constructor:

Compact Constructor:

record Point(int x, int y){      
 Point(int x, int y){
   if(x == 0 && y == 0)
    throw new IllegalArgumentException(String.format("(%d,%d)", x, y));
   this.x = x;
   this.y = y;
 }
}

record Point(int x, int y){      
 Point{
  if(x == 0 && y == 0)
   throw new IllegalArgumentException (String.format("(%d,%d)", x, y));
 }
}

List<Merchant> findTopMerchants(List<Merchant> merchants, int month) {
  // Local record
  record MerchantSales(Merchant merchant, double sales) {}

  return merchants.stream()
  .map(merchant -> new MerchantSales(merchant, computeSales(merchant, month)))
  .sorted((m1, m2) -> Double.compare(m2.sales(), m1.sales()))
  .map(MerchantSales::merchant)
  .collect(toList());
}

Local Record Classes

Continue

@_tamanm

|

JEP 394: Pattern Matching for instanceof

1st Prev JDK 14

Go to JEP 394

Final JDK 16

2nd Prev JDK 15

Pattern matching allows common logic in a program, namely the conditional extraction of components from objects, to be expressed more concisely and safely.

The use of pattern matching in instanceof should significantly reduce the overall number of explicit casts in Java programs. Consider the following equals() methods:

public boolean equals(Object o) {
   return (o instanceof CaseInsensitiveString) &&
      ((CaseInsensitiveString) o).s.equalsIgnoreCase(s);
}

public boolean equals(Object o) {
   return (o instanceof CaseInsensitiveString cis) &&
      cis.s.equalsIgnoreCase(s);
}

public boolean equals(Object o) {
   if (!(o instanceof Point))
      return false;
   Point other = (Point) o;
   return x == other.x
       && y == other.y;
}

public boolean equals(Object o) {
   return (o instanceof Point other)
     && x == other.x
     && y == other.y;
}

@_tamanm

|

JEP 406: Pattern Matching for switch (Preview)

1st Prev JDK 17

Go to JEP 406

Enhance the Java programming language with pattern matching for switch expressions and statements, along with extensions to the language of patterns.

Extending pattern matching to switch allows an expression to be tested against a number of patterns, each with a specific action, so that complex data-oriented queries can be expressed concisely and safely.

static String formatter(Object o) {
    String formatted = "unknown";
    if (o instanceof Integer i) {
        formatted = String.format("int %d", i);
    } else if (o instanceof Long l) {
        formatted = String.format("long %d", l);
    } else if (o instanceof Double d) {
        formatted = String.format("double %f", d);
    } else if (o instanceof String s) {
        formatted = String.format("String %s", s);
    }
    return formatted;
}

static String formatterPatternSwitch(Object o) {
    return switch (o) {
        case Integer i -> String.format("int %d", i);
        case Long l    -> String.format("long %d", l);
        case Double d  -> String.format("double %f", d);
        case String s  -> String.format("String %s", s);
        default        -> o.toString();
    };
}

@_tamanm

|

JEP 406: Pattern Matching for switch (Preview)

Continue

Pattern matching and null

We may wish to handle null in the same way as another case label. For example:

static void testFooBar(String s) {
    if (s == null) {
        System.out.println("oops!");
        return;
    }
    switch (s) {
        case "Foo", "Bar" -> System.out.println("Great");
        default           -> System.out.println("Ok");
    }
}

static void testFooBar(String s) {
    switch (s) {
        case null         -> System.out.println("Oops");
        case "Foo", "Bar" -> System.out.println("Great");
        default           -> System.out.println("Ok");
    }
}

static void testStringOrNull(Object o) {
  switch (o) {
      case null, String s -> System.out.println("String: " + s);
  }
}

Working with Sealed types

sealed interface S permits A, B, C {}
final class A implements S {}
final class B implements S {}
record C(int i) implements S {}  // Implicitly final


static int testSealedCoverage(S s) {
    return switch (s) {
        case A a -> 1;
        case B b -> 2;
        case C c -> 3;
    };
}

@_tamanm

|

JEP 409: Sealed Classes

1st Prev JDK 15

Go to JEP 409

Final JDK 17

2nd Prev JDK 16

Sealed classes and interfaces restrict which other classes and interfaces may extend or implement them. Therefore they can be extended or implemented only by those classes and interfaces permitted to do so.

Allow the author of a class or interface to control the code responsible for implementing it.

package com.example.geometry;

public abstract sealed class Shape
    permits Circle, Rectangle, Square, WeirdShape { ... }

public final class Circle extends Shape { ... }

public sealed class Rectangle extends Shape 
    permits TransparentRectangle, FilledRectangle { ... }
public final class TransparentRectangle extends Rectangle { ... }
public final class FilledRectangle extends Rectangle { ... }

public final class Square extends Shape { ... }

public non-sealed class WeirdShape extends Shape { ... }

Provide a more declarative way than access modifiers to restrict the use of a superclass.

Support future directions in pattern matching by providing a foundation for analysis of patterns.

A class is sealed by applying the sealed modifier to its declaration. Then, after any extends and implements clauses, the permits clause specifies the classes permitted to extend the sealed class.

@_tamanm

|

JEP 409: Sealed Classes

1st Prev JDK 15

Go to JEP 409

Final JDK 17

2nd Prev JDK 16

Here is another classic example of a class hierarchy with a known set of subclasses: modeling mathematical expressions.

Sealed classes work well with record classes. Record classes are implicitly final, so a sealed hierarchy of record classes is slightly more concise than the example above:

package com.example.expression;

public sealed interface Expr
    permits ConstantExpr, PlusExpr, TimesExpr, NegExpr { ... }

public final class ConstantExpr implements Expr { ... }
public final class PlusExpr     implements Expr { ... }
public final class TimesExpr    implements Expr { ... }
public final class NegExpr      implements Expr { ... }

package com.example.expression;

public sealed interface Expr
    permits ConstantExpr, PlusExpr, TimesExpr, NegExpr { ... }

public record ConstantExpr(int i)       implements Expr { ... }
public record PlusExpr(Expr a, Expr b)  implements Expr { ... }
public record TimesExpr(Expr a, Expr b) implements Expr { ... }
public record NegExpr(Expr e)           implements Expr { ... }

Sealing and record classes

The combination of sealed classes and record classes is sometimes referred to as algebraic data types: Record classes allow us to express product types, and sealed classes allow us to express sum types.

@_tamanm

|

C-Style Array Declarations Are Not Allowed in Record Components

JDK-8250629

Final JDK 16

Before JDK 16, the javac compiler accepted C-style array declarations in record components. In particular, the compiler had accepted code such as:

This code is no longer acceptable according to the JLS specification for JDK 16:

record R(int i[]) {}

jshell> record R(int i[]) {}
|  Error:
|  legacy array notation not allowed on record components
|  record R(int i[]) {}
|                ^

mohamed_taman -- -bash

@_tamanm

|

Annotation Interfaces May Not Be Declared As Local Interfaces

JDK-8250741

Final JDK 16

Before JDK 16, the javac compiler accepted annotations declared as local interfaces. For example, the javac compiler had accepted code such as:

This code is no longer acceptable according to Section [14.3] of the JLS 16: "A local interface may be a normal interface (§9.1), but not an annotation interface (§9.6)."

class C {
  void m() {
    @interface A {}
  }
}

jshell> class C {
   ...>    void m() {
   ...>       @interface A {}
   ...>    }
   ...> }
|  Error:
|  annotation type declaration not allowed here
|              @interface A {}
|              ^-------------^

mohamed_taman -- -bash

Agenda

Check out Java's important features!

Explore new Language Features.

Explore the new & Improved language APIs.

Farewell to APIs has gone forever.

Learn about new Tools & JVM.

✓

➥

✓

@_tamanm

|

Explore the new & Improved language APIs

Java SE API features that enrich the language. 🪙

@_tamanm

|

@_tamanm

|

Day Period Support Added to java.time Formats

JDK-8247781

Final JDK 16

A new formatter pattern, letter 'B', and its supporting method have been added to java.time.format.DateTimeFormatter/DateTimeFormatterBuilder classes.

Applications can now express periods in a day, such as "in the morning" or "at night," not just am/pm.

[mtaman]:~ ~~ jshell --enable-preview

|  Welcome to JShell -- Version 17-ea
|  For an introduction type: /help intro

jshell> import java.time.format.DateTimeFormatter

jshell> import java.time.LocalTime

jshell> DateTimeFormatter.ofPattern("B").format(LocalTime.now())
$3 ==> "at night"

mohamed_taman -- -bash

The following example translating the day periods, and produces day period text depending on the time of the day and locale:

@_tamanm

|

Add Stream.toList() Method

JDK-8180352

Final JDK 16

Since its introduction in Java 8, the Stream API was blamed for its verboseness. For example, performing a simple mapping transformation on a list requires writing as much as:

With the new edition, you can now write shorter, clearer code such as:

However, this is not just a simple shortcut. Why?

While the specification does not guarantee it, collect(toList()) produces a mutable list and many users already rely on this fact. The new method, Stream.toList(), produces an unmodifiable list. It also is not a shortcut to collect(toUnmodifiableList()) either, because toUnmodifiableList() doesn’t accept nulls.

the implementation of Stream.toList() is not constrained by the Collector interface.

As a result, Stream.toList() is more optimal and allocates less memory, especially if the stream size is known in advance.

list.stream().map(fn).collect(Collectors.toList())

list.stream().map(fn).toList()

@_tamanm

|

JEP 390: Warnings for Value-Based Classes

Go to JEP 390

Final JDK 16

Designate the primitive wrapper classes as value-based and deprecate their constructors for removal, prompting new deprecation warnings. Provide warnings about improper attempts to synchronize on instances of any value-based classes in the Java Platform.

The Valhalla Project is pursuing a significant enhancement to the Java programming model in the form of primitive classes.

jshell> Integer x = new Integer("12")
|  Warning:
|  Integer(java.lang.String) in java.lang.Integer has been deprecated and marked for removal
|  Integer x = new Integer("12");
|              ^---------------^
x ==> 12

jshell> Integer x = new Integer(12)
|  Warning:
|  Integer(int) in java.lang.Integer has been deprecated and marked for removal
|  Integer x = new Integer(12);
|              ^-------------^
x ==> 12

jshell> Integer x = 12
x ==> 12

mohamed_taman -- -bash

When running on a future Java release in which the migration has occurred:

Attempts to synchronize on instances of these classes will produce exceptions.

Attempts to create wrapper class instances with new Integer, etc., rather than implicit boxing or calls to the valueOf() factory methods, will produce LinkageErrors.

Instances of these classes that are equal (per equals()) may also be considered identical (per ==).

Such classes declare their instances to be identity-free and capable of inline or flattened representations, where instances can be copied freely between memory locations and encoded using solely the values of the instances' fields.

@_tamanm

|

JEP 380: Unix-Domain Socket Channels

Go to JEP 380

Final JDK 16

Add Unix-domain (AF_UNIX) socket support to the socket channel and server-socket channel APIs in the java.nio.channels package.

Unix-domain sockets are used for inter-process communication (IPC) on the same host. They are similar to TCP/IP sockets in most respects, except that they are addressed by filesystem pathnames rather than Internet Protocol (IP) addresses and port numbers.

To support Unix-domain socket channels, the following API elements have been added:

New open factory methods on SocketChannel and ServerSocketChannel that specify the protocol family.

A UNIX constant value in the existing java.net.StandardProtocolFamily enum.

A new socket address class, java.net.UnixDomainSocketAddress

For local, inter-process communication, Unix-domain sockets are both more secure and more efficient than TCP/IP loopback connections.

Updates to the SocketChannel and ServerSocketChannel specifications to specify how channels to Unix domain sockets behave.

@_tamanm

|

JEP 396: Strongly Encapsulate JDK Internals by Default

Go to JEP 396

Final JDK 16

Strong encapsulation of JDK internals by default, except for critical internal APIs such as misc.Unsafe. Users can choose the relaxed strong encapsulation that has been the default since JDK 9.

Relaxed strong encapsulation is controlled by the launcher option --illegal-access. In JDK 16 the default is --illegal-access=deny not --illegal-access=permit as it was since JDK 9.

Goals of this proposal include:

Developers can use an existing release, such as JDK 11, to test existing code by using --illegal-access=warn to identify internal elements accessed via reflection, using --illegal-access=debug to pinpoint errant code, and testing with --illegal-access=deny.

This proposal does carry a primary risk that existing Java code will fail to run. Developers are encouraged to use the jdeps tool to identify code that depends on internal elements of the JDK and switch to standard replacements when available.

Improving the security and maintainability of the JDK, as part of Project Jigsaw, and encouraging developers to migrate from using internal elements to using standard APIs so that both developers and end users can update easily to future Java releases.

@_tamanm

|

JEP 357: Migrate from Mercurial to Git

Go to JEP 357

Final JDK 16

Migration of OpenJDK source code repositories from Mercurial to Git. Driving this effort are advantages in version control system metadata size and available tools and hosting.

Migration to GitHub, related to the Mercurial-to-Git migration, with JDK 16 source code repositories to be on the popular code-sharing site.

JEP 369: Migrate to GitHub

Go to JEP 369

JDK feature releases and JDK update releases for Java 11 and later would be part of this plan.

The transition to Git, GitHub, and Skara for the Mercurial JDK and JDK-sandbox was done on September 5 and is open for contributions.

@_tamanm

|

JEP 389: Foreign Linker API (Incubator)

Go to JEP 389

JDK 16

Introduce an API (jdk.incubator.foreign) that offers statically-typed, pure-Java access to native code.

Foreign linker API, together with the Foreign-Memory API (JEP 393), will considerably simplify the otherwise error-prone process of binding to a native library.

Goals of this proposal include:

Generality: The Foreign Linker API and implementation should be flexible enough to, over time, accommodate support for other platforms (e.g., 32-bit x86) and foreign functions written in languages other than C (e.g. C++, Fortran).

C support: The initial scope of this effort aims at providing high quality, fully optimized interoperability with C libraries, on x64 and AArch64 platforms.

Ease of use: Replace JNI with a superior pure-Java development model.

Performance: The Foreign Linker API should provide performance that is comparable to, or better than, JNI.

@_tamanm

|

JEP 393: Foreign-Memory Access API (Third Incubator)

Go to JEP 393

JDK 16

A foreign-memory access API, allowing Java programs to safely access foreign memory outside the Java heap.

Changes have been made including a clearer separation of roles between the MemorySegment and MemoryAddresses interfaces.

Goals of this proposal include:

Control: Allow clients to deallocate memory segments: either explicitly (via a method call) or implicitly (when the segment is no longer in use).

Safety: It should not be possible for the API to undermine the safety of the JVM, regardless of the kind of memory being operated upon.

Generality: A single API should be able to operate on various kinds of foreign memory (e.g., native memory, persistent memory, managed heap memory, etc.).

1st Inc. JDK 14

2nd inc. JDK 15

Usability: To provide a compelling alternative API to legacy Java APIs such as sun.misc.Unsafe, for programs that need to access foreign memory.

@_tamanm

|

JEP 414: Vector API (Second Incubator)

Go to JEP 414

JDK 17

Introduce an API to express vector computations that reliably compile at runtime to optimal vector instructions on supported CPU architectures, thus achieving performance superior to equivalent scalar computations. And it is fitted with an incubator module, jdk.incubator.vector.

The vector API provides a mechanism to write complex vector algorithms in Java, using pre-existing support in the HotSpot VM for vectorization but with a user model that makes vectorization more predictable and robust.

Goals of this proposal include:

Graceful degradation: A vector computation would degrade gracefully and still function if it cannot be fully expressed at runtime as a sequence of hardware vector instructions, either because architecture does not support some instructions or another CPU architecture not supported.

Being platform-agnostic by supporting multiple CPU architectures and offering reliable runtime compilation and performance on x64 and AArch64 architectures.

Providing a clear and concise API to express a range of vector computations.

1st Inc. JDK 16

@_tamanm

|

JEP 387: Elastic Metaspace

Go to JEP 387

Final JDK 16

An elastic metaspace capability, which returns unused HotSpot VM class metadata (metaspace) memory more promptly to the OS, reduces metaspace footprint and simplifies metaspace code to reduce maintenance costs.

Metaspace has had issues with high off-heap memory use.

Goals of this proposal include:

The commitment of memory from the OS to memory management arenas will be done lazily, on-demand, to reduce the footprint for loaders that start with large arenas but do not use them immediately or might not use them to their full extent.

This approach has been used in places such as the Linux kernel and will make it practical to allocate memory in smaller chunks to reduce class-loader overhead. Fragmentation also will be reduced.

Replacing the existing memory allocator with a buddy-based allocation scheme, providing an algorithm to divide memory into partitions to satisfy memory requests.

To fully exploit the elasticity offered by buddy allocation, metaspace memory will be arranged into uniformly sized granules that can be committed and uncommitted independently of each other.

Agenda

Check out Java's important features!

Explore new Language Features.

Explore the new & Improved language APIs.

Farewell to APIs has gone forever.

Learn about new Tools & JVM.

✓

➥

✓

@_tamanm

|

Farewell to APIs has gone forever

Removed Java SE features that made Java slow to scale and making it cleaner. 👋👋🏻👋🏽

@_tamanm

|

New things come ... and sometimes old things have to go ...

@_tamanm

|

JEP 407: Remove RMI Activation

Go to JEP 407

Final JDK 17

Remove the Remote Method Invocation (RMI) Activation mechanism, while preserving the rest of RMI.

The RMI Activation mechanism is obsolete. It was deprecated for removal by JEP 385 in Java SE 15.

The Java EE Platform contained a technology called the JavaBeans Activation Framework (JAF). This was later renamed to Jakarta Activation as part of the Eclipse EE4J initiative.

The JavaBeans Activation and Jakarta Activation technologies are completely unrelated to RMI Activation, and they are unaffected by the removal of RMI Activation from Java SE.

@_tamanm

|

JEP 398: Deprecate the Applet API for Removal

Go to JEP 398

Final JDK 17

Deprecate the Applet API for removal. It is essentially irrelevant since all web-browser vendors have either removed support for Java browser plug-ins or announced plans to do so.

The Applet API was previously deprecated, though not for removal, by JEP 289 in Java 9.

@_tamanm

|

JEP 410: Remove the Experimental AOT and JIT Compiler

Go to JEP 410

Final JDK 17

Remove the experimental Java-based ahead-of-time (AOT) and just-in-time (JIT) compiler.

This compiler has seen little use since its introduction, and the effort required to maintain it is significant. These features were not included in the JDK 16 builds published by Oracle.

Retain the experimental Java-level JVM compiler interface (JVMCI) so that developers can continue to use externally-built versions of the compiler for JIT compilation.

Developers who wish to use the Graal compiler for either AOT or JIT compilation can use GraalVM.

@_tamanm

|

Significant Removal and Deprecation

Release Notes 16.0.1

Final JDK 16

JDK-8202343: Disable TLS 1.0 and 1.1 (versions of the TLS protocol that are no longer considered secure and have been superseded by more secure and modern versions (TLS 1.2 and 1.3))

JDK-8243559: Removed Root Certificates with 1024-bit Keys (root certificates with weak 1024-bit RSA public keys have been removed from the cacerts keystore)

JDK-8235710: Removal of Legacy Elliptic Curves (The SunEC provider no longer supports the following elliptic curves that are either obsolete or not implemented using modern formulas and techniques. To continue using any of these curves, users must find third-party alternatives.)

JDK-8257572: Parts of the Signal-Chaining API Are Deprecated (The signal-chaining facility was introduced in JDK 1.4 and supported three different Linux signal-handling API's: sigset, signal and sigaction. Only sigaction is a cross-platform, supported, API for multi-threaded processes. Both signal and sigset are considered obsolete on those platforms that still define them. Consequently, the use of signal and sigset with the signal-chaining facility is now deprecated, and support for their use will be removed in a future release.)

@_tamanm

|

Significant Removal and Deprecation

JDK-8256643: Terminally Deprecated ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon (is inherently unsafe and has been deprecated since Java 1.2. The method is now terminally deprecated and will be removed in a future release.)

JDK-8256718: Deprecated Tracing Flags Are Obsolete and Must Be Replaced With Unified Logging Equivalents (When Unified Logging was added in Java 9, several tracing flags were deprecated and mapped to their unified logging equivalent. These flags are now obsolete. To continue getting the same logging output, you must explicitly replace these flags with their unified logging equivalent.)

Obsoleted Option	Unified Logging
-XX:+TraceClassLoading	-Xlog:class+load=info
-XX:+TraceClassUnloading	-Xlog:class+unload=info
-XX:+TraceExceptions	-Xlog:exceptions=info

Release Notes 16.0.1

Final JDK 16

Agenda

Check out Java's important features!

Explore new Language Features.

Explore most of the new & Improved APIs.

Farewell to APIs has gone forever.

Learn about new Tools & JVM.

✓

➥

✓

@_tamanm

|

Learn about new Java Tools

Java SE tools that made the language more productive. 🧑‍💻

@_tamanm

|

@_tamanm

|

JEP 392: Packaging Tool

Go to JEP 392

Final JDK 16

Provide the jpackage tool for packaging self-contained Java applications.

Supports native packaging formats to give end-users a natural installation experience. These formats include:

- msi and exe on Windows,

- pkg, and dmg on macOS, and

- deb and rpm on Linux.

By default, jpackage produces a package in the format most appropriate for the system on which it is run.

Suppose you have an application composed of JAR files, all in a directory named lib, and that lib/main.jar contains the main class. Then the command:

[mtaman]:~ ~~ jpackage --name myapp --input lib --main-jar main.jar

mohamed_taman -- -bash

--main-class myapp.Main

--type pkg

@_tamanm

|

JEP 386: Alpine Linux Port

Go to JEP 386

Final JDK 16

The Alpine Linux distribution is widely adopted in cloud deployments, microservices, and container environments due to its small image size, which is less than 6 MB. That applies to embedded system deployments as well, which are constrained by size.

This JEP ports the JDK to Alpine Linux, and to other Linux distributions that use musl as their primary C library, on both the x64 and AArch64 architectures.

It will revolutionize the running of Java applications in such an environment as native applications.

Using the jlink linker, developers can cut down the Java application runtime environment size with only the required modules to run their application. Thus, the user could create a tiny image targeted to run a specific application.

@_tamanm

|

JEP 388: Windows/AArch64 Port

Go to JEP 388

Final JDK 16

With the release of new consumer and server-class AArch64 (ARM64) hardware, Windows/AArch64 has become an important platform due to end-user demand.

The JDK is ported to Windows/AArch64 by extending the work previously done for the Linux/AArch64 port (JEP 237). It supports both the Windows 10 and Windows Server 2016 operating systems.

@_tamanm

|

JEP 391: macOS/AArch64 Port

Go to JEP 391

Final JDK 17

Apple has announced a long-term plan to transition their line of Macintosh computers from x64 to AArch64. there will be a broad demand for a macOS/AArch64 port.

It accommodates differences in low-level conventions such as the application binary interface (ABI) and the set of reserved processor registers.

It implements W^X support in HotSpot for macOS/AArch64 (forbids memory segments from being executable and writeable at the same time, a policy known as write-xor-execute (W^X)).

The Cool Thing about Cool Things in Java

16 & 17 LTS 😉

Publications

You can catch me (🤝)

Here 👇

Agenda

What is the Relation between JDK 16 and 17 LTS?

Agenda

Check out Java's important features!

features that made java sexier 🥷

What behind features like

JEP 12: Preview Features

A preview feature is:

Enabling preview features during development.

JEP 11: Incubator Modules

An incubating feature is:

JEP 277: Enhanced Deprecation

Agenda

Explore new Language Features

Java SE features that made java more concise and less verbose. 🦾

JEP 395: Records

JEP 395: Records

JEP 394: Pattern Matching for instanceof

JEP 406: Pattern Matching for switch (Preview)

JEP 406: Pattern Matching for switch (Preview)

Pattern matching and null

Working with Sealed types

JEP 409: Sealed Classes

JEP 409: Sealed Classes

C-Style Array Declarations Are Not Allowed in Record Components

Annotation Interfaces May Not Be Declared As Local Interfaces

Agenda

Explore the new & Improved language APIs

Java SE API features that enrich the language. 🪙

Day Period Support Added to java.time Formats

Add Stream.toList() Method

JEP 390: Warnings for Value-Based Classes

JEP 380: Unix-Domain Socket Channels

JEP 396: Strongly Encapsulate JDK Internals by Default

Goals of this proposal include:

JEP 357: Migrate from Mercurial to Git

JEP 369: Migrate to GitHub

JEP 389: Foreign Linker API (Incubator)

Goals of this proposal include:

JEP 393: Foreign-Memory Access API (Third Incubator)

Goals of this proposal include:

JEP 414: Vector API (Second Incubator)

Goals of this proposal include:

JEP 387: Elastic Metaspace

Goals of this proposal include:

Agenda

Farewell to APIs has gone forever

Removed Java SE features that made Java slow to scale and making it cleaner. 👋👋🏻👋🏽

JEP 407: Remove RMI Activation

JEP 398: Deprecate the Applet API for Removal

JEP 410: Remove the Experimental AOT and JIT Compiler

Significant Removal and Deprecation

Significant Removal and Deprecation

Agenda

Learn about new Java Tools

Java SE tools that made the language more productive. 🧑‍💻

JEP 392: Packaging Tool

JEP 386: Alpine Linux Port

JEP 388: Windows/AArch64 Port

JEP 391: macOS/AArch64 Port

Agenda

Questions?

Thanks for listening! 🧡