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

[Rony G. Flatscher]

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

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

No, "dangerous" is meant this way: if an (end-) user all of a sudden starts to get to see this 
warning implying security problems in his application by Java/OpenJDK itself, they will be 
unsettled, upset as they would not be able to understand what the problem is all of a sudden. This 
introduces unease, a feeling of danger which needs to be addressed. Once such a perception has been 
established it is not possible to remedy the situation by not showing that warning to the (end-) 
user anymore, the damage has been done already (like in the case of the Java browser plugin where 
over time the misconception that Java is a risk for the browser's security allowed to pull it 
eventually without anyone trying to inhibit it, a strategic loss for Java).

... cut ...

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

It is not a harmless "change warning" it is a warning that something is all of a sudden risky, 
unsafe with the target to turn it into an error eventually.

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

Yes, it is by no means an easy task and one that takes a lot of nerves, but it pays! :)

>> 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.
No, it is not a fact! It is something you state wrongly.
> 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.

Yes, customed tailored runtimes for pure Java applications are not JRE, it is a crippled JRE 
relative to the one installed by default with the OpenJDK.

I am not talking about jlinked environments, but the standard JRE you gain with an OpenJDK 
installation that can be exploited by non-Java applications. That is also the reason why it is 
damaging if in a modular OpenJDK the JavaFX modules are left out which may have been used by such 
applications of Java/OpenJDK.

Something you do not realize and if pointed out assess it to not be problem for you, ignoring that 
it is a major problem for the Java/OpenJDK customers. There is a reason why there are many OpenJDK 
distributors that offer a "full" or a "fx" version of OpenJDK including the JavaFX modules.

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

Will do in a few examples that try to demonstrate the area where this will become a serious problem.

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

No, but I need to rely on a pre-installed runtime for applications that exploit Java/OpenJDK as a 
huge (ported) class library allowing for platform-independent solutions.

What you point out is the use case where a mono-Java application author wants to cut down the 
runtime burden by leaving out those modules s/he does not need for the application. This is fine 
(and important for quite a few scenarios) however incurs that updates to the tailored runtime 
environments must be published by the application author of a sudden.

However, even in the cases of mono-Java applications it may make sense to use the JRE in full if 
there are multiple mono-Java applications as this helps cut down the number of duplicate customized 
runtime environments. Updates to the Java/OpenJDK will immediately benefit all affected mono-Java 
applications.


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

Well, what do you think was the first thing to do when JavaFX got pulled from the standard 
Java/OpenJDK 11?

Right, coming up with slides that try to teach business administration students on how to go about 
to get JavaFX back.

Here the slides for that in case you are interested: cf. page 9 in 
<https://wi.wu.ac.at/rgf/wu/lehre/autojava/material/foils/280_AutoJava_Environment_V04.pdf>. BTW 
this incurred the need to teach novices in programming also about operating system processes, 
environment variables and the like, such that it took a *lot* of time from the lecture!

When it became clear that distributors of Java/OpenJDK would offer versions that included the four 
JavaFX modules I could gain back that precious time by pointing the business administration students 
to download the "full" or "fx" versions in order to get the JavaFX modules.

Ad JavaFX: with the SceneBuilder JavaFX is very easy to take advantage of. I was surprised when 
those business administration students would come up with final projects where they voluntarily 
employed JavaFX as they considered it rather easy! :)

Notabene: these are students who just learned programming in a four hour lecture (8 ECTS teaching 
load, four months a semester). After in introduction into the fundamentals of programming they learn 
to interact with Windows via OLE, with MS Office, after two months, the last two months are devoted 
to Java, becoming able to teach important software frameworks in a portable manner such that 
students with macOS and Linux systems would also be able to run the programs directly from their 
systems in addition to Windows.

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

No, I am not objecting at that at all, it is a nice goal to head for as long as for exceptional 
cases JNI is accepted without any questions asked.

What I am objecting is the expectation that only Java/OpenJDK uses Java/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.
The point is that this situation is one that cannot be compared to past ones as long as an (end-) 
user who is not Java savvy but relies that Java is a well tested, secure environment does not get to 
see this warning and would not lose execution capabilities in the future. If the application was 
save enough at the moment, it will be safe enough for the future as well sauf errors that may be 
uncovered (and fixed).
> 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.

This is where I think you can do better. Step back a few steps and look at totally different 
deployment scenarios and who would be addressed by that warning and the eventual prohibition to 
execute applications.

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

+1

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

Can any Java application author assess, appreciate and accept such a stance?

---rony