diff --git a/closed/src/java.se/share/specs/jni/intro.md b/closed/src/java.se/share/specs/jni/intro.md
index a50a0b4c62..c756fc571e 100644
--- a/closed/src/java.se/share/specs/jni/intro.md
+++ b/closed/src/java.se/share/specs/jni/intro.md
@@ -61,6 +61,9 @@ native application to embed the Java VM. This allows programmers to easily make
 their existing applications Java-enabled without having to link with the VM
 source code.
 
+Many of the uses of JNI can be achieved with the newer [Foreign Function & Memory API](../../api/java.base/java/lang/foreign/package-summary.html)
+(FFM), which should be preferred over JNI.
+
 ## Historical Background
 
 VMs from different vendors offer different native method interfaces. These
@@ -72,6 +75,7 @@ We briefly examine some of the native method interfaces, such as:
 -   JDK 1.0 native method interface
 -   Netscape's Java Runtime Interface
 -   Microsoft's Raw Native Interface and Java/COM interface
+-   The Foreign Function & Memory API
 
 ### JDK 1.0 Native Method Interface
 
@@ -111,6 +115,13 @@ standard binary interface to the Java VM. Java code can use a COM object as if
 it were a Java object. A Java class can also be exposed to the rest of the
 system as a COM class.
 
+### The Foreign Function & Memory API
+
+Many of the uses of JNI can be achieved with the newer [Foreign Function & Memory API](../../api/java.base/java/lang/foreign/package-summary.html)
+(FFM), added in JDK 22.
+
+Programmers should prefer FFM to JNI when applicable.
+
 ## Objectives
 
 We believe that a uniform, well-thought-out standard interface offers the
@@ -216,3 +227,24 @@ time tested and ensured to not impose any overhead or restrictions on your VM
 implementation, including object representation, garbage collection scheme, and
 so on. Please send us your feedback if you run into any problems we may have
 overlooked.
+
+## Integrity Concerns
+
+The use of native code in general and of JNI in particular imposes risks to the
+integrity of Java applications.
+
+-  Native code may exhibit *undefined behavior* which may lead to process crashes
+   or other undesirable unspecified behavior.
+
+-  Native JNI methods may [create a direct byte buffer](functions.html#newdirectbytebuffer) 
+   addressing illegal memory and pass it to Java code. This may lead to undefined behavior 
+   triggered by the Java code interacting with the direct byte buffer.
+
+-  Native JNI methods may call private methods, read or write private fields, and
+   generally access and manipulate Java objects without regard to access control.
+
+Consequently, the use of JNI is *restricted*. For a Java module to make use of JNI
+it must enable native access (see [Chapter 2: Design Overview](design.html)).
+
+Loading native libraries or declaring `native` methods in modules without native access
+will result in exceptions and/or warnings.