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

[Ron Pressler]

> 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. 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.

> 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.

Warnings are useful to prepare users (who may not all read JEPs and release notes) for upcoming changes. I don’t know if that’s what you refer to by “dangerous”, but such warnings have been a standard practice supporting Java’s evolution for some years now. We don’t want to impose changes without a prior warning.

> Unfortunately, I do not see that you are really doing the best that you can. You can do much better! :)

That may well be the case, but that’s not something that’s helped by mailing lists discussions.

> The "some" that you scare are those who pay in order to use Java/OpenJDK applications and who will switch ASAP.
> [See what happened to the browser Java plugin: reports of security problems with Java turned up (as wrong as they might have been in many instances) by third parties/media and after some time allowed the browser producers like Google, Apple and Microsoft to remove Java from the browser by removing the documented plugin interfaces harming Java heavily on that the very important browser market segment. So these "some" were the wrong "somes".]

This is not a security warning but an upcoming change warning, of the kind we’ve been emitting for some years now. We have not seen the effect that you fear, certainly not a large one.

> These improvements are welcome, however, please realize that every new feature that Java gains, not only makes Java more powerful, but at the same time more complex, more difficult to learn all that there has become available since Java's birth. This also makes Java more and more difficult to teach of course.
> And BTW neither records, nor patterns, etc. have anything to do with client's native code impacting them.

We understand that very well, which is why we try to be cautious. You need to understand that different Java users demand (sometimes vociferously) that we do contradictory things. But we don’t (and can’t) design a platform for millions of users based on letter-writing campaigns by few people who may care deeply about a particular subject. We need to balance conflicting wishes, and try a gradual, cautious approach that allows us to gauge impact (which is what warnings do). 

> Sorry, this is simply not the reality. Until Java 8 Java there were always two installation packages that differed only in the developer utilities bundled with it. The JDK has always been the JRE with the compiler and developer tools like javadoc etc. So one would get a JRE in any case, one without and one with development tools.
> Both versions got installed system wide with the effect that Java has been always available to all processes. So "JRE" describes the phenomenon that Java is installable globally and as such makes all its features available to third party software: Java applications, but also non-Java applications that interact with the JRE. It is exactly for this usage that JNI got invented in the first place and has since served very well both, the Java world and the Java client world.
> What is a little bit frightening, it seems that you are not aware of the non-Java-app use of Java at all. Probably because of this you may not be able/willing to accept that there is a clientele that would be overwhelmed and frightened if your proposal would be realized in its current form.

As of JDK 11, the JRE no longer exists. That is a fact. There’s the JDK, the JDK contains a Java runtime (generated with jlink), and you can create custom Java runtime with jlink. But these Java runtimes are not the JRE.

Many things about Java have changed since the old days to adapt to a changing software landscape and changing requirements. Some may not like those changes, but here we are. Those who use modern versions of Java should learn how to make the best of them, and are likely to find that they’re better than the old Java world in most ways.

However, if there’s a specific use case that you think is not properly addressed, report that in the most specific way that you can.

> Unfortunately, starting with Java 11 the four JavaFX modules got removed from most installation packages which is causing quite some damage to the Java ecosystem!

Except that it was offset by an even bigger contribution to the ecosystem in the form of jlink. One of the nice things about “new Java” is that it supports self-contained applications. You no longer need to rely on a pre-installed runtime. Instead, your application can now easily pick the runtime it chooses, configure it as it wishes (and add JavaFX), and embed it in the application. It is easier than ever before to distribute Java applications, but to do that you need to learn the new ways (including jlink). If I only looked at what’s been taken and ignore what’s replaced it, then I, too, would have had a gloomy picture.

While it would have been great if we could never remove anything without it affecting our ability to adapt to changing circumstances, or at least that adding new things wouldn’t have required users to learn new things, we don’t know how to do that. Nevertheless, we put *a lot* of effort into designing features that may not require zero effort to learn on the part of the Java developer, but as little effort as we know how. Furthermore, I think we’re doing a better job at that than other languages. Still, there’s some new learning required, but it is certainly easier than learning another language.

I agree we could do a better job creating tutorials, but there’s ongoing work on improving that: https://dev.java/

> *Exactly*, short of a bug! You cannot promise therefore "absolute integrity" as this thread of discussions implicitly communicates. You can try to guarantee as much as possible, but never absolutely.

One way to think about strong encapsulation is that of compartmentalisation that localises certain effects to specific code units. Regarding that, as well as most of the rest of your email, you may want to read the integrity JEP: https://openjdk.org/jeps/8305968

If you’d like to discuss the merits of Java’s integrity strategy that we’ve been working on for many years, I hope we get the chance to meet at a conference, but this mailing list is not a design committee, and the design is carried out by people with combined centuries of working on OpenJDK. 

We presented the JEP to see if anyone spots some serious flaw. I believe that your claim is that a warning about a future change will have a significant detrimental effect. My response is that past experience suggests that that is not the case.

Still, it’s perfectly okay not to like a feature. I’m sure every Java developer hates at least one change we’ve done in the last several years. Because developers demand contradictory thing, it is a mathematical impossibility to satisfy all of them with every change. The best we could attain is make the vast majority happy with most changes.


> What you omitted to comment were among other things:
>     • module-info (documenting the use of accessing native code JNI): why do you not comment on this idea which would allow for documenting explicitly its usage, such that simple tools can be made to create reports that also document use of JNI (and which then also should list the Java/OpenJDK modules). 

Because it’s already in the JEP as an item for Future Work. But we want to be more cautious, so we’d rather design solutions to problems once we know more about them rather than on speculation (when we can), and the JEP offers a way to do that, with the same kind of warning we’ve been using for the same purpose for years now. 

> How can an application developer possibly evaluate whether a JNI library is safe or unsafe without having the necessary skills and being able to look into the source-code? 

Think of compartmentalisation and reduction of surface area.

— Ron