<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>