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

[Rony G. Flatscher]

On 04.09.2023 12:50, Ron Pressler wrote:
>> On 4 Sep 2023, at 02:23, Glavo <zjx001202 at gmail.com> wrote:
>>
>>
>> My question is why should we distinguish between the author of the main module and the packager of the program?
> We’re not, it’s just that “the main module” is not a reified concept, but a situational one. The same module can be the main module of one application and not the main module of another. Modules are designed to declare what they themselves provide and require, not control other modules.
>
> Instead, there is a centralised place that configures all modules as well as other global settings, and that is the launcher configuration (which we call “the `java` command line”, but it can be in a configuration file). Indeed, we don’t distinguish between the author of the launcher configuration and the packager of the program. The author of the launcher configuration is what we call the application author, the application owner, the application assembler, or “the user” (of the Java runtime, not of the application).

And that person is one that creates Java applications and not an author that creates non-Java 
applications exploiting Java/OpenJDK?

... cut ...

>> I'm not saying there should be no restrictions at all. For features like this that is really needed by people, I wish it could be managed more finely.
>> This is what I want (3rd repetition):
> I’m sorry but this discussion is not a design committee. As I’m sure you imagine, all the ideas you propose, and others, have already been considered. Those that haven’t been presented have either been rejected for the time being or are simply not mature enough to be presented at this time. While we often allow short exchanges about design or feature requests on the mailing lists, the mailing lists are not where we design things in OpenJDK.
>
> We’ve presented a draft JEP to give relevant experts an opportunity to point out some major design flaws. So far we’ve heard speculation about the level of inconvenience imposed by a configuration flag and speculation about the impact of a warning. If at least one of them isn’t catastrophic — and past experience suggests that neither one is — then this isn’t a major design flaw and the JEP is reasonable.

It has been pointed out repeatedly that unfortunately this is not an "inconvenience" and that this 
cannot be remedied by (end-) users as it is not easy for them knowing nothing about the inner 
workings of Java/OpenJDK with regards to JNI and the like.

End-users and Java application authors who are not acquainted with JNI have no chance to assess 
anything the JNI modules in use do.

So trust is needed to allow them to employ JNI-dependent Java modules. If trust is not enough, then 
warnings against core Java/OpenJDK modules would be needed as well. Clearly that immediately will 
cause the need for that flag such that the entire idea in its current incarnation is rendered useless.

... cut ...

---rony