Showing posts with label jcmd. Show all posts
Showing posts with label jcmd. Show all posts

Wednesday, March 26, 2025

JDK-24: the death of SecurityManager

It has happened: after many years of deprecation warnings and back-and-forth conversations, the SecurityManager is effectively dead. JDK-24, released just last week, sets a final point in this long story. But there is no time to grieve, so many new features in JDK-24 to talk about!

The JDK-24 is really packed with JEPs, nonetheless some of them are being dragged from the previous JDK releases. Let us kick off from the finalized features first, with the preview / experimental / incubating to follow right after.

  • JEP-472: Prepare to Restrict the Use of JNI: issues warnings about uses of the Java Native Interface (JNI) and adjusts the Foreign Function & Memory (FFM) API to issue warnings in a consistent manner. All such warnings aim to prepare developers for a future release that ensures integrity by default by uniformly restricting JNI and the FFM API. Application developers can avoid both current warnings and future restrictions by selectively enabling these interfaces where essential.

    Code that uses JNI is affected by native access restrictions if

    The following warnings are going to be issued:

         WARNING: A restricted method in java.lang.System has been called
     WARNING: java.lang.System::loadLibrary has been called by com.example.LoadLibraryRunner in an unnamed module (...)
     WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module
     WARNING: Restricted methods will be blocked in a future release unless native access is enabled

    As per the hints above, to enable native access selectively, you could use the following command-line options:

    • $ java --enable-native-access=ALL-UNNAMED ... (all code on the class path)
    • $ java --enable-native-access=M1,M2, ... (specific modules on the module path)

    Alternatively, you could add Enable-Native-Access: ALL-UNNAMED to the manifest of an executable JAR file (MANIFEST.MF). The only supported value for the Enable-Native-Access manifest entry is ALL-UNNAMED; other values cause an exception to be thrown. For more details, please check Quality Outreach Heads-up - JDK 24: Prepares Restricted Native Access write-up.

  • JEP-498: Warn upon Use of Memory-Access Methods in sun.misc.Unsafe: issues a warning at run time on the first occasion that any memory-access method in sun.misc.Unsafe is invoked. All of these unsupported methods were terminally deprecated in JDK 23. They have been superseded by standard APIs, namely the VarHandle API (JEP 193, JDK 9) and the Foreign Function & Memory API (JEP 454, JDK 22).

    In case when usage of the sun.misc.Unsafe memory-access methods is detected, the following warnings are going to be issued:

         WARNING: A terminally deprecated method in sun.misc.Unsafe has been called
     WARNING: sun.misc.Unsafe::allocateMemory has been called by com.example.UnsafeRunner (...)
     WARNING: Please consider reporting this to the maintainers of class com.example.UnsafeRunner
     WARNING: sun.misc.Unsafe::allocateMemory will be removed in a future release

  • JEP-491: Synchronize Virtual Threads without Pinning: improves the scalability of Java code that uses synchronized methods and statements by arranging for virtual threads that block in such constructs to release their underlying platform threads for use by other virtual threads. This will eliminate nearly all cases of virtual threads being pinned to platform threads, which severely restricts the number of virtual threads available to handle an application's workload.

  • JEP-475: Late Barrier Expansion for G1: simplifies the implementation of the G1 garbage collector's barriers, which record information about application memory accesses, by shifting their expansion from early in the C2 JIT's compilation pipeline to later.

  • JEP-479: Remove the Windows 32-bit x86 Port: removes the source code and build support for the Windows 32-bit x86 port. This port was deprecated for removal in JDK 21 with the express intent to remove it in a future release.

  • JEP-490: ZGC: Remove the Non-Generational Mode: removes the non-generational mode of the Z Garbage Collector (ZGC), keeping the generational mode as the default for ZGC.

  • JEP-501: Deprecate the 32-bit x86 Port for Removal: deprecates the 32-bit x86 port, with the intent to remove it in a future release. This will thereby deprecate the Linux 32-bit x86 port, which is the only 32-bit x86 port remaining in the JDK. It will also, effectively, deprecate any remaining downstream 32-bit x86 ports. After the 32-bit x86 port is removed, the architecture-agnostic Zero port will be the only way to run Java programs on 32-bit x86 processors.

  • JEP-493: Linking Run-Time Images without JMODs: reduces the size of the JDK by approximately 25% by enabling the jlink tool to create custom run-time images without using the JDK's JMOD files. This feature must be enabled when the JDK is built; it will not be enabled by default, and some JDK vendors may choose not to enable it.

  • JEP-496: Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism: enhances the security of Java applications by providing an implementation of the quantum-resistant Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM). Key encapsulation mechanisms (KEMs) are used to secure symmetric keys over insecure communication channels using public key cryptography. ML-KEM is designed to be secure against future quantum computing attacks. It has been standardized by the United States National Institute of Standards and Technology (NIST) in FIPS 203.

  • JEP-497: Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm: enhances the security of Java applications by providing an implementation of the quantum-resistant Module-Lattice-Based Digital Signature Algorithm (ML-DSA). Digital signatures are used to detect unauthorized modifications to data and to authenticate the identity of signatories. ML-DSA is designed to be secure against future quantum computing attacks. It has been standardized by the United States National Institute of Standards and Technology (NIST) in FIPS 204.

  • JEP-484: Class-File API: provides a standard API for parsing, generating, and transforming Java class files. This JEP finalizes the Class-File API that was originally proposed as a preview feature by JEP 457 in JDK 22 and refined by JEP 466 in JDK 23.

  • JEP-486: Permanently Disable the Security Manager: removes the abilities to enable the Security Manager when starting the Java runtime (java -Djava.security.manager ...) or to install a Security Manager while an application is running (System::setSecurityManager).

    It is worth to mention that the impacted APIs changes are going way beyond just Security Manager, notably:

  • JEP-483: Ahead-of-Time Class Loading & Linking: improves startup time by making the classes of an application instantly available, in a loaded and linked state, when the HotSpot Java Virtual Machine starts. Achieve this by monitoring the application during one run and storing the loaded and linked forms of all classes in a cache for use in subsequent runs. Lay a foundation for future improvements to both startup and warmup time.

    This one is probably the first tangible deliverable of the Project Leyden, and an exciting one. The process to create a cache takes two steps.

    First, run the application once, in a training run, to record its AOT configuration, in this case into the file app.aotconf:

        $ java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar com.example.App ...

    Second, use the configuration to create the cache, in the file app.aot (this step doesn’t run the application, it just creates the cache):

        $ java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot -cp app.jar

    Subsequently, in testing or production, run the application with the cache (if the cache file is unusable or does not exist then the JVM issues a warning message and continues):

        $ java -XX:AOTCache=app.aot -cp app.jar com.example.App ...

    • The process is somewhat verbose at the moment, but no doubts, there are strong indications that the improvements are coming in the next release(s).

  • JEP-485: Stream Gatherers: enhances the Stream API to support custom intermediate operations. This will allow stream pipelines to transform data in ways that are not easily achievable with the existing built-in intermediate operations.

    From the API perspective, the changes include:

    Please check recently published The Gatherer API tutorial for more in-depth API design overview and different usage scenarios.

It was a lot but we are far from done yet, the list of preview / experimental / incubating features is as impressive:

  • JEP-478: Key Derivation Function API (Preview): introduces an API for Key Derivation Functions (KDFs), which are cryptographic algorithms for deriving additional keys from a secret key and other data. This is a preview API feature.

  • JEP-487: Scoped Values (Fourth Preview): introduces scoped values, which enable a method to share immutable data both with its callees within a thread, and with child threads. Scoped values are easier to reason about than thread-local variables. They also have lower space and time costs, especially when used together with virtual threads (JEP 444) and structured concurrency (JEP 480). This is a preview API feature.

  • JEP-489: Vector API (Ninth Incubator): introduces 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.

  • JEP-499: Structured Concurrency (Fourth Preview): simplifies concurrent programming by introducing an API for structured concurrency. Structured concurrency treats groups of related tasks running in different threads as a single unit of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability. This is a preview API feature.

  • JEP-494: Module Import Declarations (Second Preview): enhances the Java programming language with the ability to succinctly import all of the packages exported by a module. This simplifies the reuse of modular libraries, but does not require the importing code to be in a module itself. This is a preview language feature that we have covered previously.

  • JEP-488: Primitive Types in Patterns, instanceof, and switch (Second Preview): enhances pattern matching by allowing primitive types in all pattern contexts, and extend instanceof and switch to work with all primitive types. This is a preview language feature that we have covered previously.

  • JEP-404: Generational Shenandoah (Experimental): enhances the Shenandoah garbage collector with experimental generational collection capabilities to improve sustainable throughput, load-spike resilience, and memory utilization. This experimental feature could be activated through the JVM command line options:

    $ java -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational ...

  • JEP-450: Compact Object Headers (Experimental): reduces the size of object headers in the HotSpot JVM from between 96 and 128 bits down to 64 bits on 64-bit architectures. This will reduce heap size, improve deployment density, and increase data locality. This experimental feature could be is activated through the JVM command line options:

    $ java -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders ...

  • JEP-492: Flexible Constructor Bodies (Third Preview): in constructors in the Java programming language, allows statements to appear before an explicit constructor invocation, i.e., super(..) or this(..). The statements cannot reference the instance under construction, but they can initialize its fields. Initializing fields before invoking another constructor makes a class more reliable when methods are overridden. This is a preview language feature.

  • JEP-495: Simple Source Files and Instance Main Methods (Fourth Preview): evolves the Java programming language so that beginners can write their first programs without needing to understand language features designed for large programs. Far from using a separate dialect of the language, beginners can write streamlined declarations for single-class programs and then seamlessly expand their programs to use more advanced features as their skills grow. Experienced developers can likewise enjoy writing small programs succinctly, without the need for constructs intended for programming in the large. This is a preview language feature.

The amount of features we just looked at is astonishingly large for just one release, but let us take a look on some other fixes and improvements that went into JDK-24:

The JDK-24 tooling updates bring some new capabilities and deprecations:

Sadly, there are few regressions to be aware of that sneaked into JDK-24 release:

Last but not least, let us look over the changes to the standard library:

To close up, a couple of security related enhancements that deserve closer look:

I think it is fair to say that JDK-24 is an outstanding (and at the same time, disruptive to some) release that prepares the ground for the next LTS version, JDK-25, which is expected to land later this year.

I 🇺🇦 stand 🇺🇦 with 🇺🇦 Ukraine.

Posted by at No comments:
Labels: , , , , , , , , , , , , , ,

Thursday, October 5, 2023

JDK-21: green threads are officially back!

The JDK-21 is there, bringing virtual threads (back) into JVM as a generally available feature (if you are old enough like myself, you might have remembered that in Java 2 releases prior to 1.3 the JVM used its own threads library, known as green threads, to implement threads in the Java platform). This is big, but what else is coming?

  • JEP-431: Sequenced Collections: introduces new interfaces to represent collections with a defined encounter order. Each such collection has a well-defined first element, second element, and so forth, up to the last element. It also provides uniform APIs for accessing its first and last elements, and for processing its elements in reverse order.

    The following new interfaces have been introduced (and retrofitted into the existing collections type hierarchy), potentially a breaking change for some library implementors:

  • JEP-439: Generational ZGC: improves application performance by extending the Z Garbage Collector (ZGC) to maintain separate generations for young and old objects. This will allow ZGC to collect young objects — which tend to die young — more frequently.

    By default, the -XX:+UseZGC command-line option selects non-generational ZGC, but to select the Generational ZGC, additional command line option -XX:+ZGenerational is required: 

    $ java -XX:+UseZGC -XX:+ZGenerational ...

  • JEP-440: Record Patterns: enhances the Java programming language with record patterns to deconstruct record values. Record patterns and type patterns can be nested to enable a powerful, declarative, and composable form of data navigation and processing. This is certainly a huge step towards having a powerful, feature-rich pattern matching capabilities in the language:

        interface Host {}
    record TcpHost(String name, int port) implements Host {}
    record HttpHost(String scheme, String name, int port) implements Host {}

    The are several places the records could be deconstructed, instanceof check being one of those:

        final Host host = new HttpHost("https", "localhost", 8080);
    if (host instanceof HttpHost(var scheme, var name, var port)) {
        ... 
    } else if (host instanceof TcpHost(var name, var port)) {
        ...
    }

  • JEP-441: Pattern Matching for switch: enhances the Java programming language with pattern matching for switch expressions and statements. 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.

    Considering the example with the records deconstruction from above, we could use record patterns in switch expressions too:

            var hostname = switch(host) {
            case HttpHost(var scheme, var name, var port) -> name;
            case TcpHost(var name, var port) -> name;
            default -> throw new IllegalArgumentException("Unknown host");
        };

    But the switch patterns are much more powerful, with guards to pattern case labels, null labels, etc.

            final Object obj = ... ; 
        var o = switch (obj) {
            case null ->  ... ;
            case String s -> ... ;
            case String[] a when a.length == 0 -> ... ;
            case String[] a -> ... ;
            default ->  ... ;
        }

  • JEP-444: Virtual Threads: introduces virtual threads to the Java Platform. Virtual threads are lightweight threads that dramatically reduce the effort of writing, maintaining, and observing high-throughput concurrent applications. The virtual threads and executors could be used along the traditional ones, following the same familiar API:

        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
        executor.submit(() -> {
                ...
        });
    }

    Some of the quirks of the virtual threads we have discussed previously here and here, but there is one more: you could use them in parallel streams, but should you? The answer is a bit complicated, so referring you to Virtual Threads and Parallel Streams article if you are looking for clarity.

    The JDK tooling (like jcmd and jfr) has been updated to include the information about virtual threads where applicable.

    The jcmd thread dump lists virtual threads that are blocked in network I/O operations and virtual threads that are created by the ExecutorService interface. It does not include object addresses, locks, JNI statistics, heap statistics, and other information that appears in traditional thread dumps (as per Viewing Virtual Threads in jcmd Thread Dumps).
    Java Flight Recorder (JFR) can emit these events related to virtual threads (as per Java Flight Recorder Events for Virtual Threads):
    • jdk.VirtualThreadStart and jdk.VirtualThreadEnd (disabled by default)
    • jdk.VirtualThreadPinned (enabled by default with a threshold of 20 ms)
    • jdk.VirtualThreadSubmitFailed (enabled by default)

    It is worth noting that Oracle has published a comprehesive guide on virtual threads as par of JDK-21 documentation update.

  • JEP-449: Deprecate the Windows 32-bit x86 Port for Removal: deprecates the Windows 32-bit x86 port, with the intent to remove it in a future release.

  • JEP-451: Prepare to Disallow the Dynamic Loading of Agents: issues warnings when agents are loaded dynamically into a running JVM. These warnings aim to prepare users for a future release which disallows the dynamic loading of agents by default in order to improve integrity by default. Serviceability tools that load agents at startup will not cause warnings to be issued in any release.

    Running with -XX:+EnableDynamicAgentLoading on the command line serves as an explicit "opt-in" that allows agent code to be loaded into a running VM and thus suppresses the warning. Running with -XX:-EnableDynamicAgentLoading disallows agent code from being loaded into a running VM and can be used to test possible future behavior.

    In addition, the system property jdk.instrument.traceUsage can be used to trace uses of the java.lang.instrument API. Running with -Djdk.instrument.traceUsage or -Djdk.instrument.traceUsage=true causes usages of the API to print a trace message and stack trace. This can be used to identify agents that are dynamically loaded instead of being started on the command line with -javaagent.

  • JEP-452: Key Encapsulation Mechanism API: introduces an API for key encapsulation mechanisms (KEMs), an encryption technique for securing symmetric keys using public key cryptography. The new APIs are centered around javax.crypto.KEM and javax.crypto.KEMSpi abstractions.

  • JEP-430: String Templates (Preview): enhances the Java programming language with string templates. String templates complement Java's existing string literals and text blocks by coupling literal text with embedded expressions and template processors to produce specialized results. This is a preview language feature and API.

  • JEP-453: Structured Concurrency (Preview): simplifies concurrent programming by introducing an API for structured concurrency. Structured concurrency treats groups of related tasks running in different threads as a single unit of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability. This is a preview language feature and API.

  • JEP-443: Unnamed Patterns and Variables (Preview): enhances the Java language with unnamed patterns, which match a record component without stating the component's name or type, and unnamed variables, which can be initialized but not used. Both are denoted by an underscore character, _. This is a preview language feature.

  • JEP-445: Unnamed Classes and Instance Main Methods (Preview): evolves the Java language so that students can write their first programs without needing to understand language features designed for large programs. Far from using a separate dialect of Java, students can write streamlined declarations for single-class programs and then seamlessly expand their programs to use more advanced features as their skills grow. This is a preview language feature.

  • JEP-446: Scoped Values (Preview): introduces scoped values, values that may be safely and efficiently shared to methods without using method parameters. They are preferred to thread-local variables, especially when using large numbers of virtual threads. This is a preview language API.

    In effect, a scoped value is an implicit method parameter. It is "as if" every method in a sequence of calls has an additional, invisible, parameter. None of the methods declare this parameter and only the methods that have access to the scoped value object can access its value (the data). Scoped values make it possible to pass data securely from a caller to a faraway callee through a sequence of intermediate methods that do not declare a parameter for the data and have no access to the data.

  • JEP-442: Foreign Function & Memory API (3rd Preview): introduces an API by which Java programs can interoperate with code and data outside of the Java runtime. By efficiently invoking foreign functions (i.e., code outside the JVM), and by safely accessing foreign memory (i.e., memory not managed by the JVM), the API enables Java programs to call native libraries and process native data without the brittleness and danger of JNI. This is a preview language API.

  • JEP-448: Vector API (6th Incubator): introduces 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.

Those JEPs are the themes of JDK-21 but what other features are coming? There are quite a few to unpack to be fair.

The JDK-21 changeset looks already impressive but ... we are not done yet, let us walk through the standard library changes.

From the security perspective, JDK-21 is pretty packed with enhancements. Some of them we have highlighted above but a few more deserve special mentions (if you need a comprehensive look, please check out JDK 21 Security Enhancements article):

From all perspectives, JDK-21 looks like the release worth migrating to (it is supposed to be LTS), despite the fact there are unforeseen delays announced by some vendors.

I 🇺🇦 stand 🇺🇦 with 🇺🇦 Ukraine.

Posted by at No comments:
Labels: , , , , , ,
Subscribe to: Comments (Atom)