<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi Ron,</p>
    <p>the problem in a nutshell:</p>
    <ul>
      <li>the warning is addressed to "application users/authors", i.e.
        users who create an application and a runtime to go with that
        application; <br>
        the intent, if understood correctly, is to make sure that an
        application user/author does not inadvertently use modules that
        use FFM, hence the idea of that warning that goes away if the
        application user/author supplies an appropriate switch; <br>
        the problem: it is likely that that warning bypasses the
        application user/authors and instead gets presented to the (end)
        user, the user of the Java application; <br>
        the reason why this is possible lies in the fact that the Java
        runtime that gets used is not necessarily controllable by the
        application author; <br>
        the (end) user is not to be expected to know necessarily Java or
        have the expert knowledge necessary to assess what the warning
        is really about, such that the effect will be to frighten the
        (end) user and to create the impression that it has become
        dangerous to use Java all of a sudden; <br>
        it is likely that the (end) users will not have the necessary
        knowledge or means (if the Java programs and Java applications
        run under a globally installed JRE without any specific
        launchers) to stop these messages<br>
        <br>
      </li>
      <li>authors of plain-vanilla jars cannot inhibit that warning
        (confined currently to executable jars only)<br>
        <br>
      </li>
      <li>authors of modules cannot inhibit that warning <br>
        <br>
      </li>
      <li>and in JRE deployment scenarios not even the authors can
        inhibit that warning if they do not control the configuring of
        the JVM <br>
      </li>
    </ul>
    <p>Please also realize that using the term "Java/JDK runtime
      environment (JRE)" is just a generic technical term that denotes a
      deployment in which any Java/JDK got installed globally on a
      computer such that any Java program and any Java application will
      use in any process the currently installed JRE. <br>
    </p>
    <p>"JRE" therefore describes the environment in which the warning
      may appear once Java/JDK gets updated to 22 replacing the old with
      a new JRE without anyone expecting such a warning who uses a Java
      program and Java application. Worse, the warning has the potential
      to scare those users, which has the potential of destroying the
      good reputation of Java, as these Java programs and Java
      applications all of a sudden turned dangerous.</p>
    <p>There is no good side-effect for "application users/authors" in
      this scenario ("ha, the (end) users will ultimately force those
      stubborn 'application authors' to supply that harmless switch!")
      as mostly the (end) users cannot do anything about it. But the
      negative effect that Java warns users from using Java has
      materialized. In social environments like companies, departments
      one is not able to remedy that situation once the trust got
      broken. Rather it is a good reason to start leaving Java and
      change to other environments. <br>
    </p>
    <p>It is about two totally different domains (this expert group and
      the users of Java software) where the effects will be totally
      different. The fear (from experience) is that that warning will
      cause significant and hardly reparable damage to Java.</p>
    <p>The problem solution is in principle rather easy: do not show
      that warning to users of Java programs and Java applications, show
      it only to the application authors for whom it got invented for. <br>
    </p>
    <p>---</p>
    <p>As there has been quite a lot of communication so far, it should
      have become clear that there are Java savvy people who see a real
      and serious problem and urge to make sure that that warning is not
      shown to (end) users. <br>
    </p>
    <p>Trying to help understand the deployment scenarios for people who
      are focused exclusively on applications that go only with their
      own runtime (and for which the warning can easily be fixed by the
      application authors), I will try to come up with a few very short
      samples with deployment scenarios where this is not the case,
      where the currently installed JRE gets employed. <br>
    </p>
    <p>Maybe you can look at these few scenarios (stripped down) and
      assess the problem in these scenarios? <br>
    </p>
    <p>---rony<br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 15.09.2023 18:51, Ron Pressler
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:74481268-76C8-4AA1-8DDF-BA624586D9D2@oracle.com">
      <pre class="moz-quote-pre" wrap="">

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">On 15 Sep 2023, at 15:46, Rony G. Flatscher <a class="moz-txt-link-rfc2396E" href="mailto:Rony.Flatscher@wu.ac.at"><Rony.Flatscher@wu.ac.at></a> wrote:

Hi Ron,
first thank you very much for your interesting answer!
There seem to be a few problems that make the communication delude at times therefore trying to pointing them out upfront: 
    • one is the term JRE which is supposed to identify the use case of a Java/JDK runtime installed in a system that gets used by any Java and non-Java application in each process
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Right. You’re referring to a shared runtime. The client JRE was similar in some ways but different in other important ways (e.g. it supported automatic updates for both the runtime and the applications running on it) and in any event — no longer exists.

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">; what you seem to be focusing on is only the "CRE" (customized - "embedded" - runtime environment) use case where an application developer determines/controls the configuration of the CRE s/he uses for her/his Java application,

    • another is the error message and who gets addressed by it introduced with FFM: the target use is the "application user" i.e. the application developer.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
The target is whoever needs to put the application and its runtime together, because that’s the person who needs to be aware the two may not be compatible. Because the recommendation is that the application author picks the runtime, it can certainly be the application author. But if for some reason or another the application author chooses not to pick the runtime and to place that responsibility on the user, then the user must be warned that the runtime they’ve picked is not right for the application.

You, the application author, can choose what your users are exposed to.

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">As various posters have pointed out the proposed warning these (end) users get will be frightening (it will appear out of the blue for them once the JRE gets updated to the version that issues that warning) and they will most likely be afraid and not know what to do to remedy this unexpected, all of the sudden "dangerous" situation,
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Indeed, if the application author chooses to place that responsibility on their users, the users will (and should) be “frightened”. The solution we’ve offered since JDK 9 is for the application author not to place that burden on the users.

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">
    • another is about the control over which runtime environment gets used, the JRE or the CRE, and who loads up the JVM: it seems that the expectation is that the "application author" is in full control over the JVM loading and that the only relevant use case is the CRE one, not the JRE one; as has been pointed out one of the biggest values of Java/JDK is its "compile once, run anywhere" supplying an incredible wealth of functionality in its JRE to whomever is able to exploit it: non-Java programs, non-Java tools got JNI by any of the Java JDKs in the past decades. The JRE deployment scenarios are manyfold, e.g. commands, utilities may be employed in a pipe using whatever runtime environment is present of which they may not know who started it in the first place. As such it is not possible to make sure that the warning does not get shown to the (end) user when there are different JRE's in use (even different JRE versions available on the same machine),
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
For better or worse, the JRE was retired some years ago. You can try to mimic much its functionality with a custom non-embedded runtime (which is what you’re using for versions of Java past 8), but the experience is not quite the same as in the days where there was a JRE. The form in which Java offers write-once-run-anywhere changed some years ago, when we retired the JRE. On the negative side you may no longer be able to deploy the same file for all platforms; on the positive side, you don’t need to ask your users to install a Java runtime and deal with incompatibilities (that experience has become even more difficult since the JRE was retired because neither the runtime nor the application are now self-updating).

The fact is that Java’s recommended deployment model changed some years ago. I think that in most ways it’s now much better than it’s ever been, and in some small ways it’s worse. But trying to recreate the old experience with newer JDKs is sure to result in an experience that’s worse than either one offers. 

</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">
    • another one is "what is easy for whom" where the knowledge of this group seems to be the reference, but the knowledge of the Java application users/developers out in the field cannot be on par if they did not follow the project's discussions closely; add to that users who have no deep Java (language) knowledge at all and really constitute end users, people who work in departments on a computer and use their acquired programming skills to ease their business processes by taking advantage of them (like the PDFBox example).
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
That is where jlink can solve your problem, but not if you choose not to use it.

— Ron</pre>
    </blockquote>
    <pre class="moz-signature" cols="100">
</pre>
  </body>
</html>