JDK-8318304 : Release Note: JEP 454: Foreign Function & Memory API
  • Type: Sub-task
  • Component: core-libs
  • Sub-Component: java.lang.foreign
  • Affected Version: 22
  • Priority: P4
  • Status: Resolved
  • Resolution: Delivered
  • Submitted: 2023-10-17
  • Updated: 2024-02-20
  • Resolved: 2023-12-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 22
22Resolved
Description
The Foreign Function & Memory API allows Java programs to interoperate with code and data outside of the Java runtime.

Access to foreign memory is realized via the `MemorySegment` class. A memory segment is backed by a contiguous region of memory, located either off-heap or on-heap. Safe and deterministic deallocation of off-heap memory segments is provided via the `Arena` class. Structured access to memory segments is realized via the `MemoryLayout` class. A memory layout can be used to compute the size and offsets of struct fields, and to obtain var handles that read and write the data in memory segments.

Access to foreign functions is realized via the `Linker` class. The native linker can be used to obtain method handles that provide a fast way for Java code to invoke native code. Native code is invoked using the calling convention for the OS and processor where the Java runtime is executing, so Java code is not polluted with platform-specific details. Native code can also call back into Java code.

Native code is generally unsafe; if used incorrectly, it might crash the JVM or result in memory corruption. Some of the methods in the Foreign Function & Memory API are considered unsafe because they provide access to native code. These unsafe methods are *restricted*, which means their use is permitted but causes warnings at run time. Developers can compile their code with `-Xlint:restricted` to learn if it will produce warnings at run time due to use of unsafe methods.

If the risks associated with native code are understood, then unsafe methods can be used without warnings at run time by passing `--enable-native-access=...` on the `java` command line. For example, `java --enable-native-access=com.example.myapp,ALL-UNNAMED ...` enables warning-free use of unsafe methods by code in the `com.example.myapp` module and code on the class path (denoted by `ALL-UNNAMED`). Additionally, in an executable JAR, the manifest attribute `Enable-Native-Access: ALL-UNNAMED` enables warning-free use of unsafe methods by code on the class path; no other module can be specified. When the `--enable-native-access` option or JAR manifest attribute is present, any use of unsafe methods by code outside the list of specified modules causes an `IllegalCallerException` to be thrown, rather than a warning to be issued.
Comments
Release notes need to be either Resolved - Delivered or Resolved - Withdrawn.
11-12-2023