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

[Ron Pressler]

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

> 
> This reason would lead me to believe it if the same restrictions were not imposed on Panama.
> I support more restrictions on JNI to move users to Panama, but I would like Panama to be available without JVM options.

That subject is under discussion by the relevant designers, but irrelevant to this particular JEP.

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

> 
> I know you have some descriptions in the "future work", but you are now preparing to modify the default behavior of the program.
> Even just printing a warning is not harmless, it is urging the user to go somewhere.
> So please don't let them be "future work", they should be "dependencies".

If you work out the immediate practical implications of the items in the Future Work section, you’ll see that they’re probably not large and urgent (because most programs don’t have more than a couple of native libraries, and most aren’t modularised anyway). If fear of either flags or warnings is the issue, then the Future Work won’t have the immediate and large effect to assuage that fear (and neither will moving the launcher configuration into module-info). 

So rather than work on things that may not address big, immediate problems, we’d like to be more cautious and start with something basic that will then inform our future priorities. Moreover, when we’re ready to seriously consider a future change, such as a future restriction of JNI, we want to start the public process as soon as possible so that people have more time to prepare and we get some actionable insight sooner.

> 
> I think future I/O should be limited in a similar way, since users can use it to break integrity as well. 
> For example, using /proc/pid/mem can bypass the restriction and write directly to memory.

The integrity JEP addresses that in the Non-Goals section. The Java runtime offers the integrity invariants that it’s best positioned to offer, while other components offer the integrity invariants they are better positioned to offer.

— Ron