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

[Ron Pressler]

> On 2 Sep 2023, at 12:57, Glavo <zjx001202 at gmail.com> wrote:
> 
> I think I've calmed down now. Now let me calmly sort out the issues in our dispute:

I’m glad that you’ve calmed down, but at the risk of sounding harsh, let me point out that the purpose here is not to conduct a debate or to design a feature as a committee (it is possible to more actively participate in the design process, but it requires a significant amount of commitment), but to see if there is some serious flaw with what’s being proposed, in this case — issuing a warning on the use of JNI.

On the matter of “opinion feedback” the problem isn’t that we don’t want to hear negative opinions, but that there’s nothing constructive we can do with them (which isn’t to say you shouldn’t express them, but I think it does mean that the negative *tone* needs to be toned down). In a situation like this where we’re forced to balance two contradictory needs, negative opinions are a mathematical certainty no matter what we do or don’t do, and what we’re proposing is the gentlest thing we can do and think would still give us the information we need to choose our next steps.

I would like to think that the portion of Java users who are happy *overall* with what we deliver — including the features they like, dislike, or don’t care much about — is as close to 100% as can hope to get; I certainly don’t think it’s lower than that of other super-popular languages, and even some less-than-super-popular languages. I don’t think it’s possible to have everyone like every feature.

But let me address one point that I think is interesting:

> 
>     2. JNI has been widely used, but it has not actually hindered JDK development by being abused to break integrity.

This is absolutely true. However:

1. Some operations, especially mechanical program transformations, that require absolute certainty. High likelihood won’t cut it (e.g. is dropping an unused private method from the image a valid meaning-preserving transformation? If JNI is used, the answer is always no).

2. Unfortunately, there are some (low level) libraries determined to offer the capability to sneakily circumvent strong encapsulation, and they use whatever means at their disposal. Currently there are several, and JNI is not the most convenient one, so it’s not commonly used for that purpose. However, as the integrity JEP says, to offer integrity by default, *all* will need to be restricted (gradually and carefully, of course). If the other methods were restricted but not JNI, those libraries will use JNI for that purpose.

BTW, it took years of work on features like ModuleHandles.Lookup, VarHandles, modules, and FFM, to reach the point where we can offer integrity by default.

Of course, integrity by default — for whatever set of integrity invariants are chosen — is predicated on the assumption that most applications will not need to opt out of integrity. This JEP, that doesn’t restrict JNI but only warns will allow us to further evaluate our options and their cost/benefit based on real usage feedback rather than speculation, in our usual careful and considered way.

> 
> 2. You're emphasizing that there is an "end user" independent of the developer, not even the author of the main module, which confuses me.

No, there’s some misunderstanding here. The “end user” from the perspective of the JDK is the application author/maintainer. It is not the end user of the Java *application*.

— Ron