New candidate JEP: 454: Foreign Function & Memory API

[Rony G. Flatscher]

On 11.09.2023 22:21, Mark Reinhold wrote:
> https://openjdk.org/jeps/454
>
>    Summary: Introduce 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 JEP includes the "|--enable-native-access=M" and "||/.../ |the JAR-file manifest attribute 
|Enable-Native-Access: ALL-UNNAMED| can be used /in an executable JAR//.../"||

Can you explain how to inhibit the warning in JRE (Java/JDK runtime environment) deployment cases 
where neither a monolithic Java app nor an executable jar causes the JVM to get started up?

---

Ad "JRE":

  * A "JRE deployment case" gets established whenever OpenJDK gets installed in a system and thereby
    creating a Java/JDK runtime environment available for each process. Such a JRE deployment case
    is the standard deployment of OpenJDK and allows any Java application to be run. It has the
    benefit that one can use the same JRE for different Java applications (saving a lot of space)
    and in the case that a security update is needed for the currently installed JRE (the current
    system wide OpenJDK installation) it is sufficient to update the JRE and fix the critical
    situation for all the Java applications running under it at once.

  * A JRE deployment allows for non-Java applications like OpenOffice/LibreOffice to start the JVM
    and interact with it via JNI (the "other interaction direction" - from native to Java - for
    where JNI is the only solution).

  * A JRE deployment also allows for creating (little) programs, utilities and commands in non-Java
    languages that interact with the JRE and which may even allow for other non-Java programs to
    take advantage of the Java/JDK infrastructure in a platform independent manner which makes this
    deployment type very attractive in addition.
    Here an example in which there is also a short video demonstration at the end showing how a
    Python program can easily take advantage of Java2D without having itself any direct connection
    to Java at all (it also demonstrates how one could exploit that same utility even from Java
    programs using simple string commands to exploit Java2D instead of directly interacting with the
    Java2D Java classes): https://zenodo.org/record/8003114 (it is a five minute video demonstrating
    how simple string commands can be used to create Java2D graphics including some small animation
    examples in a platform independent manner, i.e. all the samples work unchanged on Windows, Linux
    and macOS).

There are many more deployment scenarios, of course, where it is important to realize that 
non-Java-savvy (end) users directly or indirectly take advantage of a JRE and who would not be able 
to understand why a serious warning would be shown all of a sudden by Java/JDK, what it really means 
and how to resolve it.

The JRE deployment is important for mixed operating system shops where using Java/JDK insulates the 
users from being locked-in into a certain operating system. As one of many possible examples the 
following link points to a Bachelor thesis of a business administration student who researched the 
Java tool PDFBox from the ASF (Apache Software Foundation) in order to become able to create, 
change, process/analyze PDF files, including signing PDF files and validation of signed PDF files or 
proper PDF/A; this work is a nice source of "PDF-how-to" and every Java programmer would immediately 
become able/jump start to take advantage of PDFBox in pure Java as well: 
<https://wi.wu.ac.at/rgf/diplomarbeiten/BakkStuff/2023/202303_Wang_ooRexx_and_PDFBox.pdf>. All the 
nutshell samples there run unchanged on Windows, Linux and macOS thanks to the JRE! (The student 
would be overwhelmed if all of a sudden a serious warning occurs about the usage of JNI and would 
hardly be able to understand why and how to solve that problem.)

---

As has been mentioned multiple times in the other e-mail thread on this particular planned warning 
it is really important to shelter these kind of users from that warning. There have been various 
constructive suggestions how one could go about it. Please do not ignore!

---rony

P.S.: In the discussion on the other e-mail thread it has become clear that the user who is supposed 
to be addressed with that particular warning is supposed to be the application author to make 
her/him aware that FFM gets employed in modules s/he uses which may be overseen otherwise. Therefore 
the warning should be issued in the toolset s/he has to use to build the application (probably 
jlink, jar, javac).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230913/a1eb9c55/attachment.htm>