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

[Ron Pressler]

> On 29 Aug 2023, at 10:09, Ron Pressler <ron.pressler at oracle.com> wrote:
> 
> 
> 
>> 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

P.S.

When people encountered difficulties upgrading from 8 they didn’t say, oh, this and that library we’re using is reaching into internals which has obviously made our application non-portable so we expected upgrades to break once the pace of the JDK development picked up; no, they were surprised! They didn’t know that their applications became non-portable, they didn’t know why, and they never realised they were sacrificing portability for something.

People also file JDK tickets when their JVM crashes due to a library’s use of native code or Unsafe, and the often don’t even know that a library does that.

So the way we see it, far more people are absolutely against not having integrity by default (even if they don’t know that that’s what they’re asking for), and the inconvenience they’re experiencing is far higher than that of adding a flag. With strong encapsulation by default or without it, someone is inconvenienced. 

Our responsibility is to find the way that causes the least inconvenience overall, and we think we’ve found it. Saying “ignore other people’s inconvenience, just take care of mine” is not helpful. Obviously every person complains about their own inconvenience, but if you’d like to help us you’ll need to offer a way that takes *everyone* into account, including people who care about security and people who want the JDK to evolve faster while also offering smooth upgrades (at least once they’re past the initial hump).

— Ron