Minor thoughts (Re: [External] : Re: JEP draft: Prepare to Restrict The Use of JNI

[Andrew Dinn]

On 05/09/2023 10:43, Rony G. Flatscher wrote:
> On 04.09.2023 15:31, Ron Pressler wrote:
>>> On 4 Sep 2023, at 13:00, Rony G. Flatscher <Rony.Flatscher at wu.ac.at> 
>>> wrote:
>>>
>>> The major break was with the module system where some Java 
>>> applications would not be allowed to execute anymore.
>> That is simply incorrect, but it is, sadly a common misconception. 
>> Strong encapsulation of JDK internals was only turned on in JDK 16; 
>> until then it was exactly the same as it was in Java 8.
> No, it was not. Before turning on errors warning got issued and caused 
> most of the Java application landscape to stick with Java 8.

I am afraid you need to actually underpin that claim with some evidence. 
My experience (gained from working for Red Hat for the last 16 years, an 
organization that supports an enormous number of Java users and also 
provides middleware that is used by an even larger number of users) is 
that there are many reasons why people do not upgrade their deployments 
to run on a later Java release. I believe that the single most important 
one is that the OpenJDK community expends great efforts to make it safe 
to continue deployment without upgrade for many years.

What that implies is that the key metric you should be looking at at 
here to support your claims that a wrong step was taken is how many 
users choose not to deploy newly developed applications on later 
releases. The continued, long-term support for legacy releases means 
that is still a real choice and one that your users can make (your 
Jeremiads as to the terrors that lie in wait for them notwithstanding).

It is true that some developers still continued to develop new 
applications for deployment on jdk8 after jdk9 was released. It seems 
fairly clear to me that the main delay in take-up of jdk9 was the 
inability of various libraries and middleware to accommodate straight 
away to the changes modules introduced. However, my experience is that 
most new deployments since jdk11 and jsdk17 were released have been 
developed for deployment on those new releases. Also that they have been 
able to do that because most of the libraries and middleware they depend 
on have also kept up with new releases.

Of course there are some tools, libraries and applications that need to 
operate on multiple releases that span the jdk8-9 bridge. Indeed I am in 
that position with Byteman. I had to rework Byteman to ensure that more 
recent releases could continue run in a JDK without modules but also 
adapt to run in a JDK which included modules. I also kept an old legacy 
version alive in order to allow JBoss Modules users to retain 
functionality that can only work in a non-modularised JDK. Perhaps you 
should really be thinking about how to make your code migrate to use FFM 
as a replacement for JNI and thereby avoid the problems for your users 
that you are so concerned about?

>> The reason for the difficulty upgrading from 8 was that some libraries 
>> reached into JDK internals and made their clients non-portable (Java 
>> only offers backward compatibility on the supported APIs). The reason 
>> things worked for a while is simply because the JDK has changed slowly 
>> for some years. When the pace picked up and JDK internals changed, 
>> applications broke. Modules and their strong encapsulation aren’t the 
>> cause of the breakage; they’re the measure that will prevent such 
>> things from recurring.
> This is astonishing as this is one of the major reasons of breakage.

I think you are taking a very short-sighted view in making that 
statement. However much Java developers pre-jdk9 felt they were could 
safely rely on the continued existence of classes in package like 
com.sun.* etc they made a grave mistake in doing so. Those classes were 
not actually offered as something that was guaranteed to exist in any 
JDK runtime -- the clue is in the (package) name. These *implementation* 
classes were hidden behind interfaces and omitted from the Java API 
documentation for a good reason. They were merely mechanism for 
implementing the language runtime that could easily have been replaced 
with some alternative and at some pint probably would be for at least 
some subset of the classes.

Using undocumented code is always a risk. It s very unfortunate that in 
the rush to deploy their Java apps so many early users of Java ignored 
that risk or did not even recognize that it was being taken. If nothing 
else there was no guarantee that assumptions about how those 
implementation classes work-- assumptions  that might have been valid 
when an app or library was developed -- would remain so in some later 
revision. The danger is not just that invariants assumed by the 
application will fail to hold. A worse danger is that invariants assumed 
by the revised implementation will no longer be respected by the 
application's use of these internal APIs i.e. that the application will 
damage proper operation of the runtime platform. The worst case scenario 
is that this happen in subtle, indirect ways that end up corrupting 
application data in unknown and irreparable ways, including persistent data.

However, your response here is effectively to blame the JDK devs who 
have tried carefully to mitigate and, eventually, eliminate that risk. 
Are you sure you want to stand by that?

>>> The problem here is - and it is interesting that you seem to not be 
>>> willing to understand - that this is not "some inconvenience", it is 
>>> a message to users of Java based applications and Java classes that 
>>> what they are using is dangerous, even if this is not true at all. In 
>>> today's world issuing the words "danger" or "warning" by authorities 
>>> in public will put almost everyone into panick mode, then into 
>>> petrification mode and then into action mode to move away (from Java 
>>> in this case) to some "safer" solution.
>> Over the past five years Java has frequently issued some warnings 
>> precisely for the same reason: That the application, if unchanged, may 
>> stop working in some *future* release due to an upcoming change. This 
>> is exactly what the warning in this JEP warns about, too.
> 
> And such warnings are not harmless. The warning in essence says: "if you 
> do not adhere your program will not run anymore". So the appearance of a 
> warning gets the character of blackmailing.

If this change were being instituted for some exploitative reason then 
blackmail might be an appropriate word to use. However, to use that word 
to describe a change that is being made in order to ensure that a 
specific form of risk is both visible and able to be managed is frankly 
quite insulting. Would you please adopt a more decent tone in future 
correspondence?

<snip>

regards,


Andrew Dinn
-----------