<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi there,</p>
<p>Mark Reinhold asked to bring this forward from jdk-dev to this
discussion list. <br>
</p>
<p>---rony<br>
</p>
<div class="moz-forward-container"><br>
<br>
-------- Forwarded Message --------
<table class="moz-email-headers-table" cellspacing="0"
cellpadding="0" border="0">
<tbody>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">Subject:
</th>
<td>Re: New candidate JEP: 454: Foreign Function &
Memory API</td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">Date: </th>
<td>Wed, 13 Sep 2023 18:33:07 +0200</td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">From: </th>
<td>Rony G. Flatscher <a class="moz-txt-link-rfc2396E" href="mailto:Rony.Flatscher@wu.ac.at"><Rony.Flatscher@wu.ac.at></a></td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">To: </th>
<td><a class="moz-txt-link-abbreviated" href="mailto:jdk-dev@openjdk.org">jdk-dev@openjdk.org</a></td>
</tr>
</tbody>
</table>
<br>
<br>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">On 11.09.2023 22:21, Mark Reinhold
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:20230911202105.86C47647DC3@eggemoggin.niobe.net">
<pre class="moz-quote-pre" wrap=""><a class="moz-txt-link-freetext" href="https://openjdk.org/jeps/454" moz-do-not-send="true">https://openjdk.org/jeps/454</a>
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.
</pre>
</blockquote>
<p>This JEP includes the "<code>--enable-native-access=M" and "</code><code><i>...</i>
</code>the JAR-file manifest attribute <code>Enable-Native-Access:
ALL-UNNAMED</code> can be used <i>in an executable JAR</i><i>
...</i>"<code></code></p>
<p>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?</p>
<p>---</p>
<p>Ad "JRE": <br>
</p>
<ul>
<li>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.<br>
</li>
</ul>
<ul>
<li>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). <br>
</li>
</ul>
<ul>
<li>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. <br>
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): <a
class="moz-txt-link-freetext"
href="https://zenodo.org/record/8003114"
moz-do-not-send="true">https://zenodo.org/record/8003114</a>
(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).</li>
</ul>
<p>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.</p>
<p>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:
<a class="moz-txt-link-rfc2396E"
href="https://wi.wu.ac.at/rgf/diplomarbeiten/BakkStuff/2023/202303_Wang_ooRexx_and_PDFBox.pdf"
moz-do-not-send="true"><https://wi.wu.ac.at/rgf/diplomarbeiten/BakkStuff/2023/202303_Wang_ooRexx_and_PDFBox.pdf></a>.
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.)</p>
<p>---<br>
</p>
<p>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!<br>
</p>
<p>---rony</p>
<p>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).<br>
</p>
<p><br>
</p>
</div>
<br>
</body>
</html>