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

[Ron Pressler]

> On 1 Sep 2023, at 19:01, Glavo <zjx001202 at gmail.com> wrote:
> 
> You keep emphasizing "end user", trying to prove that you are giving more power to the end user.
> Is this real? It doesn't look like it. You are just forcing more obligations on them.

Quite the opposite! An application developer (to clarify yet again, the user we’re talking about is the application developer as opposed to the library developer; the end user *of the application* obviously need not even see any of these flags) who wanted to ensure their application enjoys Java's integrity (to make sure it’s portable across JDK version and platforms, that it may enjoy the full spectrum of optimisations the JVM can offer etc. etc.) had two options: Either they had to install a SecurityManager and configure it properly (and SM was simply not scalable for modern server-side application with their wide range of dependencies) or perform a full analysis of the codebase. Either one of these, if tractable at all, required *a lot* of work (alternatively, when things weren’t portable, they broke in complex ways that made migrations hard). Now, thanks to years of work on things like MethodHandles.Lookup, VarHandles, and FFM, we’re nearing the point that the work that will be required is, well, nothing at all! On the other hand, all applications that want to use libraries with various superpowers need to do is supply some flags. All this work is now allowing us to drastically reduce the overall effort.

Now I’d like to say something general about feedback. Java users demand things that are contradictory; it is simply impossible to satisfy them all. Our job is to take into account those contradictory demands and find a path that provides the most value for the least cost when integrated over the ecosystem as a whole. Obviously, no matter what we do or don’t do, some portion of users will be negatively affected and they’ll have a negative opinion of some change or lack thereof. Such opinions are inescapable, but also unhelpful. Obviously some people weren’t happy when applications broke when migrating from 8 to 9 because Java didn’t have integrity by default, while others aren’t happy that integrity by default requires them to add a flag when they want to selectively give up on integrity. Similarly, I hope it goes without saying that the time and money that went into designing and developing the features that allow us to achieve integrity by default in the hopefully no-so-distant-future, by people with cumulative centuries of work on OpenJDK behind them, represents a significant amount of thinking.

So that some people won’t be thrilled with anything we do or don’t do and would like us to do or not do the opposite is just a given, not valuable feedback; neither is offering other designs on the mailing list. Valuable feedback could be finding some fundamental problem (although that’s not to say that even other kinds of feedback don’t lead to various late-stage tweaks, as has been the case pretty much always). 

But even that is not enough, because very few people can provide such feedback. That is why we’re so cautious and do things gradually. The JEP under discussion will not restrict the use of JNI, just *prepare* to restrict it by issuing a warning. This will allow us to get actual information from more users in the field to see, for example, whether adding a flag to disable the warning is indeed a burden that the ecosystem cannot take or not. No amount of speculation by anyone can replace the insight that would be gained by issuing such a warning in the JDK. Even with all the planning and work, we’re virtually never confident enough to change behaviour without a preparatory step, first. For new language and even API features, that step is Preview; for others it’s the kind of warning described by the JEP.

— Ron

P.S.

While I gladly respond to people on social media regardless of their tone, we try to aim for a higher standard of decorum and respect on the mailing lists.