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

[Ron Pressler]

> On 29 Aug 2023, at 00:28, Glavo <zjx001202 at gmail.com> wrote:
> 
> I think your ideas are too jumpy.
> 
> I agree that modules that require native access need to actively disclose their behavior.
> I think it can be debated whether some form of authorization is required for native access, 
> and I am more inclined to agree.
> 
> However, I am absolutely against enforcing encapsulation breaking and having to authorize with JVM options.
> I don't think this has any positive meaning. Compared with the first two steps, it does not help security and
> does not help users' right to know, but brings usability problems.
> 
> Glavo

I don’t understand how you can think that. 

First, it is quite obviously impossible to construct any robust secure mechanism in any layer without strong encapsulation. No application, framework, or the JDK itself can establish *any* invariant, including any security invariant such as “this operation is always done after some check” without strong encapsulation (and it has only been like that, BTW; that’s why SecurityManager also had to provide strong encapsulation, including control over JNI, in addition to its security checks).

Second, we’ve seen the migration pain caused by the lack of strong encapsulation when people upgraded from JDK 8 to 9+.

So strong encapsulation is what’s required to offer the ability to have security for those who care about it, and it is essential to allow the JDK to evolve in the pace that I think we’d all like it to evolve.

Yes, we’re aware of the inconvenience such changes cause, but it’s like someone looking at a working crew digging up the street and saying, “nobody asked for this noise and dirt and traffic disruption; why can’t you just give us what we asked for — fast internet!”

I’m also surprised about the “usability problems” you bring up. Java has always been configured through the command line (either directly or in @files) and Java applications quite frequently use dozens of command-line options. A Java developer saying that command line options are a usability problem is like a Java developer complaining about the empty braces in record declarations by claiming that braces are really hard to type. Setting command line options is what Java developers do all the time, and features like @files and jlink make them particularly convenient, but if you have another idea on how to better offer strong encapsulation by default, I’d love to hear it.

— Ron