<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<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">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">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"><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>
</body>
</html>