New candidate JEP: 454: Foreign Function & Memory API

[David Alayachew]

> Having said all that, we’ll consider adding a line to the warning saying,
“If you’re not the author of this application, please report this issue to
the application vendor."

Please do this! I've run into this exact issue multiple times, so it would
have been a welcome line to read back then.

On Thu, Sep 14, 2023 at 12:38 PM Ron Pressler <ron.pressler at oracle.com>
wrote:

>
>
> > On 14 Sep 2023, at 13:21, Rony G. Flatscher <Rony.Flatscher at wu.ac.at>
> wrote:
> >
> > 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!
> > ---rony
>
> Hi.
>
> We do offer simple ways to shelter application users from warnings. Even
> when a Java runtime is shared, the application needs to create a JVM
> process (e.g. as you do on line 4569 of BSF4ooRexx.cc), at which point it
> can configure the JVM as it wishes, including to suppress the warning.
>
> The warning warns of a real (upcoming) incompatibility between the
> application and the Java runtime, and it is addressed to whoever it is that
> combines the application with the Java runtime because that’s who needs to
> handle such an incompatibility (the incompatibility is that the program is
> calling a restricted method without enabling native access, which will fail
> in a future release).
>
> As of JDK 9, the JDK provides the an application author with the ability
> to select a compatible runtime. That offers the application's user a
> superior experience to the one Java offered up until JDK 8. In that case,
> the warning — which is aimed at the person who picks the runtime — will be
> shown only to the application author (unless they choose not to suppress
> it).
>
> Also, just so that we’re clear on terminology, I assume that by “JRE” you
> mean a shared runtime, i.e. a Java runtime that’s intended to be shared
> among multiple applications (the JRE was retired five years ago and no
> longer exists).
>
> Now, not only did we not ignore the issue you raise, but we’d spent years
> considering and designing a solution before delivering it some years ago.
> Of course, the solution cannot solve the problem if you choose not to use
> it. If you care about an issue, consider the features and recommendations
> that Java has offered for the past years to address that very issue. It’s
> possible you have considered jlink and found a problem — if so, report it —
> but the fact that you refer to the JRE, a component that was retired some
> years ago, suggests that perhaps you have not fully considered its superior
> replacement (well, superior in most things if not all).
>
> I sense a fundamental misunderstanding that I think is at the core of the
> matter:
>
> An embedded runtime could do whatever a shared runtime can do and what the
> JRE could do back when it existed. In fact, the application gets to choose
> what its runtime can do. In particular, if the application so chooses, an
> embedded runtime could run arbitrary user-provided Java code. It is *not*
> necessarily tied to a specific set of classes. Indeed, even the runtime
> embedded in the JDK is generated in the same way that any other application
> or SDK can generate their own embedded Java runtimes, i.e. with jlink. Each
> and every one of the use cases you listed will offer a superior experience
> if it went down this recommended path. An application like LibreOffice can
> — and should! — use an embedded Java runtime to run users’ Java code. Same
> goes for a Java2D Python library and for BSF4ooRexx. Their users'
> experience will be better.
>
> However, if application authors choose not to avail themselves of the
> ability to pick a runtime and insist on foisting on their users the
> selection of an appropriate Java runtime — a task that’s been made more
> onerous since the discontinuation of the JRE five years ago — then yes, it
> will suffer from the same shortcoming of the JRE age (and worse, because
> today’s shared runtimes do not offer some important client JRE features).
> Those users, who the application author entrusts with selecting a Java
> runtime for the application, *must* be warned about an incompatibility
> between the application code and the runtime they’ve chosen.
>
> Put simply, if you, an application owner, pick the runtime, then only you
> will be the one seeing the warning. But if you choose not to do that and
> are asking me, your application user, to pick a runtime for your
> application, I need to be warned when I’ve picked an incompatible one.
> You’re complaining about how scary a red beach flag is when the actual
> danger is the water. You can choose to build a nice swimming pool for your
> users or you can choose to let them wade into the ocean, but letting them
> wade into the ocean without appropriate warning is just irresponsible. So
> either use an embedded runtime and offer your users a much improved
> experience, or not, and accept that they will need to be warned about
> issues that they — not you — will have to face as a result of your choice.
>
> Having said all that, we’ll consider adding a line to the warning saying,
> “If you’re not the author of this application, please report this issue to
> the application vendor."
>
> — Ron
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230914/33a91007/attachment.htm>