<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 02/09/2023 10:25, Ron Pressler wrote:
    <blockquote
      cite="mid:9E246351-1B7E-4D7B-8664-09737F8388F7@oracle.com"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">On 2 Sep 2023, at 08:06, Simon Nash <a class="moz-txt-link-rfc2396E" href="mailto:simon@cjnash.com"><simon@cjnash.com></a> wrote:

As I pointed out in my earlier message, although the end user of the application does not need to specify the flag, they do see the scary warning written to stderr when the flag is not present. This will happen when an a older version of an application that uses JNI is run on a newer version of the JDK.
</pre>
      </blockquote>
      <pre wrap="">
They do not need to see the flag even if the flag is there. We’re talking about flags passed to the JVM, not to the application launcher. Also, all JVM flags can, as always, be put in configuration @files; there’s no need to actually type them on the command line.</pre>
    </blockquote>
    I think you have misunderstood what I wrote. I was agreeing with you
    that application end users don't see the flag. My point was that
    they do see the warning (see below).
    <blockquote
      cite="mid:9E246351-1B7E-4D7B-8664-09737F8388F7@oracle.com"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">
This will scare these end users and is likely to reinforce the incorrect perception that Java is unsafe and Java-based applications should be avoided.
</pre>
      </blockquote>
      <pre wrap="">
Java has been issuing warnings like this multiple times over the past five years. Another one was just added in JDK 21. This is the standard practice in Java to prepare for future changes.
</pre>
    </blockquote>
    You have not addressed my point that the end user of the application
    will see this scary warning when they are using a Java application
    that is doing nothing wrong (the application is just using a well
    written and well behaved JNI bridge to a well written and well
    behaved external C++ library).<br>
    <br>
    What is the end user of the application supposed to do when they see
    the following?<br>
    <pre><code>WARNING: A native method in org.baz.services.Controller has been bound
WARNING: Controller::getData in module org.baz has been called by com.foo.Server in an unnamed module
WARNING: Use --enable-native-access=org.baz to avoid a warning for native methods declared in org.baz
WARNING: Native methods will be blocked in a future release unless native access is enabled</code></pre>
    The end user of my application doesn't know what a native method is
    or what --enable-native-access=org.baz means. They are being told to
    use --enable-native-access=org.baz but what can they do to obey this
    instruction? Only the developer of the application is able to make
    this change. The only thing the application end user can do is to
    stop using my application and use another similar application that
    is not written in Java and possibly even more dangerous but does not
    emit scary warning messages.<br>
    <br>
    Simon<br>
  </body>
</html>