Java 24 introduced new rules for using Java Native Interface. Starting with that version, application developers will have to explicitly enable the use of JNI at startup. Otherwise, Java will print a warning message:

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

The new rules especially affect the desktop software, because major UI toolkits depend on native calls for things like rendering and OS integration.

In this article, we explain how to enable JNI access in Java 24 in the Java applications that use JxBrowser and one of the major UI toolkits: JavaFX, SWT, Swing, and Compose Desktop.

Why restrict native access? 

We’ve specialized in JNI for over 15 years, so we understand why the time has come for new restrictions. Combining native code with Java was never easy. The Java world is tidy, with its automatic memory management and access control. But the native world is more of a wild west — full of verbal conventions but no strictly enforced rules. Put the two together, and you get both great power and great risks.

The problem is largely about memory safety. Native languages like C and C++ are not memory-safe: they don’t automatically allocate or free memory, they don’t track whether pointers remain valid, and they don’t enforce array bounds. As a result, the memory management falls entirely on the developer, making native code prone to memory-related bugs — and notoriously so.

Bugs in memory management are dangerous. In JNI code specifically, they can corrupt the memory used by Java code and cause crashes.

The authors of the original proposal offer the following example: a native function can take a reference from Java and misuse it as a raw memory address. Writing to that address will corrupt the JVM memory and cause it to crash at an unpredictable moment:

void Java_pkg_C_setPointerToThree__J(jlong ptr) {
    // This will corrupt the JVM memory.
    *(int*)ptr = 3;
}

Another risk is that native code can read and modify Java object members without access control. This includes changing final fields and even mutating objects that are meant to be immutable, such as strings.

The lack of access control and memory management can both compromise the integrity of a Java program. That’s why Java tightens the rules for native access, with the ultimate goal of achieving integrity by default.

Starting with Java 24, application developers must use the --enable-native-access command line parameter to list the modules that require JNI access:

java --enable-native-access=module1,module2

Below, you will find the instructions on how to enable JNI for JavaFX, SWT, Compose Desktop, and JxBrowser.

How to enable native access 

Native access is essential for every major UI toolkit. Without it, they can’t create windows, handle scaling, or even render components on the screen. If you’re using JavaFX, SWT, or Compose, you’ll need to enable native access to launch your application without warnings.

Swing has native access enabled by default, because it’s part of the core Java library.

The users of JxBrowser will need to enable the native access too. We use native code for such critical things as inter-process communication with Chromium and interaction with the OS.

JxBrowser 

To launch an application that uses JxBrowser without warnings, configure the --enable-native-access the following way:

  • For modular applications, add the jxbrowser module to the list:

    java --enable-native-access=jxbrowser,module1,module2

  • For non-modular applications, use the ALL-UNNAMED wildcard:

    java --enable-native-access=ALL-UNNAMED

If you’re using JxBrowser 8.12.0 or earlier in a modular SWT application, add the jxbrowser-swt module to the list. That is not required in OSGi environments like Eclipse RCP, because they don’t use Java modules.

JavaFX 

To launch an JavaFX application without warnings, you must add the necessary JavaFX modules to the --enable-native-access command line parameter.

The single required module for every JavaFX application is javafx.graphics:

java --enable-native-access=jxbrowser,javafx.graphics

If your application uses javafx.media or javafx.web, you must add them to the list too:

java --enable-native-access=jxbrowser,javafx.graphics,javafx.media,javafx.web

SWT 

To run an SWT or Eclipse application without a warning, enable the native access by setting the ALL-UNNAMED to the --enable-native-access command-line argument.

Most SWT applications don’t use the module path, because they run inside an OSGi environment. Hence, we use ALL-UNNAMED. But if you happen to use SWT in the modular application, you will need to enable native access to one of the platform-specific modules:

java --enable-native-access=jxbrowser,org.eclipse.swt.win32.win32.x86_64

Here’s the list of SWT modules for each platform:

  • org.eclipse.swt.win32.win32.x86_64
  • org.eclipse.swt.win32.win32.aarch64
  • org.eclipse.swt.linux.gtk.x86_64
  • org.eclipse.swt.linux.gtk.aarch64
  • org.eclipse.swt.cocoa.macosx.x86_64
  • org.eclipse.swt.cocoa.macosx.aarch64

Compose Desktop 

Compose Desktop relies on native access for both OS interaction and rendering. It delegates OS interaction to AWT, which has native access enabled by default, but does its own rendering through the native Skia library.

As of now, Compose Desktop is not modular. To run a Compose Desktop application without warnings, add the ALL-UNNAMED to the --enable-native-access command-line argument:

java --enable-native-access=ALL-UNNAMED

Resources 

Sending…

Sorry, the sending was interrupted

Please try again. If the issue persists, contact us at info@teamdev.com.

Read and agree to the terms to continue.

Your personal JxBrowser trial key and quick start guide will arrive in your Email Inbox in a few minutes.