New candidate JEP: 454: Foreign Function & Memory API

[Ron Pressler]

> 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