<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Pedro,<br>
</p>
<div class="moz-cite-prefix">On 15.09.2023 18:18, Pedro Lamarão
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAC8PkgFWsp3D2Pz-uNd8L20R=peed0eLm1wJTy0eMd9FpC8sDQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">Em sex., 15 de set. de 2023 às 12:34, Rony G.
Flatscher <<a href="mailto:Rony.Flatscher@wu.ac.at"
moz-do-not-send="true" class="moz-txt-link-freetext">Rony.Flatscher@wu.ac.at</a>>
escreveu:<br>
</div>
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div>This person must add whatever initialization
flags are appropriate and/or required whenever
they become appropriate and/or required.</div>
<div>Suppose this person assembles an application
including component XPTO, and this person desires
to upgrade XPTO to new version 123 that adds a new
feature that uses the new FFI: during this
upgrade, this person also adds
--enable-native-access to the initialization
flags, and all is good. If this person is not
aware of this need, it will become aware
during testing, because the JVM will alert of this
necessity.</div>
</div>
</div>
</blockquote>
<p>This is about deployment scenarios where no new
applications get created from scratch, but there are
Java applications and little Java utilitiy programs, but
also native applications and little native utilities
that have been deployed with a JRE available, possibly
for many years. Take also into account that older
versions may be deployed on newer JREs and the like.
This warning aimed at application authors should never
be placed in front of (end) users.<br>
</p>
</div>
</blockquote>
</div>
<div><br>
</div>
<div>This hypothetical situation where warnings are shown to end
users can only happen when the application is upgraded to (1)
use a new JVM, and (2) use (a new version of a component that
uses) the new restricted methods of the new FFI.<br>
</div>
</div>
</blockquote>
<p>Unfortunately also those who have been using JNI for decades
without any problems whatsoever.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAC8PkgFWsp3D2Pz-uNd8L20R=peed0eLm1wJTy0eMd9FpC8sDQ@mail.gmail.com">
<div dir="ltr">
<div>I have been reading the discussion on the new warnings and
so far have not visualized a concrete situation where these
two upgrades would happen in such a way that it is severely
inconvenient to modify the application launcher to add new
flags.</div>
</div>
</blockquote>
<p>The problem are (end) users who do not have the expertise of this
group and who have never had a need to configure the JVM as a
normal "java someJavaClass" would have been sufficient to run a
Java program. <br>
</p>
<p>Such users would get out of the blue (!) a serious warning that
is actually only aimed at "application authors" who create full
blown Java applications. Users who would not be aware of the
rationale and the intention and users who are not able to fix that
alarming situation on their own.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAC8PkgFWsp3D2Pz-uNd8L20R=peed0eLm1wJTy0eMd9FpC8sDQ@mail.gmail.com">
<div dir="ltr">
<div>I can only assume that the deployment scenarios being
considered are all about dropping modified JARs into
preexisting CLASSPATHs of preinstalled applications with no
other configuration action.</div>
<div>But such "on the fly upgrades" requires a level of module
compatibility justified only by "bugfix" changes.</div>
<div>Upgrading the native bindings of an application does not
seem to me a change to be made "on the fly" like this.</div>
<div>Even if the module ABI is preserved, this would be too
severe a change.</div>
</div>
</blockquote>
<p>This another problem in this context: the assumptions and
mind-sets that one might have regarding the execution of Java
programs and Java applications. <br>
</p>
<p>Or with other words: it does not meet reality to assume that
everyone who runs a Java program or a Java application does so by
installing a specific individual Java program that comes with a
specific JRE such that s/he (needs to) control/s the configuration
of each individual JRE. <br>
</p>
<p>Rather it is a normal deployment scenario that a JRE gets
installed globally on a machine that serves all Java programs and
Java applications available/installed there. Then an update to a
bug fix version or to a newer Java/JDK version will affect all
those Java programs and Java applications immediately as their JRE
got changed with a single, simple update.</p>
<p>It is in that scenario where the warning aimed at application
authors will be - short of an application author - be presented to
(end) users out of the blue, and a serious warning too! They will
not be able to know why and what to do, but rather they will get
the warning that something is serious wrong with their Java
program or Java application causing even a warning by Java! <br>
</p>
<p>Please realize that the preoccupation is not about this group
(expert Java developers with an incredible experience and
knowledge in particular areas of Java) of people in the know. For
you and others this does not pose a serious problem, especially as
long as you do not realize that there are use cases where this
"harmless" warning instead creates serious problems, rather
quickly destroying the trust in Java if Java warns about using
Java programs and Java applications suddenly. <br>
</p>
<p>As it is astonishingly difficult to communicate the problem at
hand I will try to come up with a few very short samples that
hopefully are able to make one aware about standard JRE
deployments (no matter which version of Java) that are more than
sufficient to run any normal Java program and normal Java
application. In such deployments no configuration of the JVM is
usually necessary and users may as a result no even be aware of
them.<br>
</p>
<p>---rony<br>
</p>
<br>
</body>
</html>