JEP draft: Prepare to Restrict The Use of JNI

[Quân Anh Mai]

Hi,

There is a huge difference between --add-opens and --enable-native-access
here. While the sole purpose of --add-opens is to break encapsulation and
open implementation details, dependence on which is a major factor causing
the friction of migration from 8 to 9, the purpose of JNI is not to break
anything, but to simply enable native accesses from Java. While
encapsulation breakage is possible in JNI, equating it as its sole purpose
seems illogical. As a result, forcing the users to treat it similarly as
--add-opens and friends seems not to be reasonable to me.

Thanks,
Quan Anh

On Tue, 29 Aug 2023 at 06:27, Ron Pressler <ron.pressler at oracle.com> wrote:

>
>
> > On 28 Aug 2023, at 23:04, Constantin Christoph <4evnyuij at gmail.com>
> wrote:
> >
> > But now, what if instead of making an application using a JNI-using
> library, I am making a library using JNI myself? I have absolutely zero
> control over whether JNI will work when my library is used, it is up to the
> user of the library to figure out that a flag needs to be added to the
> startup arguments. Now imagine that a few more libraries are in between my
> library (using JNI), and the end user. The JNI-heavy feature is now behind
> several layers of abstraction, and may not even get called until a very
> niche use case happens, and if the startup argument isn't present at that
> time, the program crashes. A notice from me regarding my library's usage of
> JNI *will* be overlooked at some point, and you can't always feasibly catch
> errors like this in testing.
>
> See the Future Work section. Modules offer strong encapsulation
> (integrity) and reliable configuration. Now that we have a model for both,
> we can offer them at different times.
>
> >
> > This is just another example of what will inevitably happen when these
> changes are in full effect, and the tradeoff is just not worth the hours of
> lost developer time that will undoubtedly need to be sacrificed to fix
> issues like these.
> >
> > As mentioned, a fix to issues like these would be to either
> > - Make the JNI flag a module setting; or
> > - Make JNI usage opt-out instead of opt-in; or
> > - Don't restrict JNI usage at all.
> >
> > This is my final stance on the subject manner: The changes should not be
> made in their current state. You just cannot change such an old interface
> that drastically, a lot of libraries will break, and a lot of developers
> will be disappointed.
>
> You say that a tradeoff is not worth it but only mention one of its arms.
> Still, you can disagree about the tradeoff, but requiring the addition of a
> couple more tokens to a command line that has dozens more is not drastic.
> Yes, it is certainly true that we’re changing something and, sadly,
> providing integrity by default requires us to do just that in multiple
> areas. What has changed drastically is the pace in which the JDK is
> changing (*much* faster now than ever before in the last 20 years) and the
> way it is written (more in Java, less in native, which makes the platform
> more sensitive to Java-level integrity guarantees). I hope and believe that
> most Java users think that’s a very, very good thing. But to allow that, we
> have to make some (hopefully not as drastic) changes in the way a Java
> application is composed and deployed, because we saw the pain caused by
> lack of integrity in the 8 -> 9+ migration, and we don’t want that risk to
> continue forever. So yes, there will be some work required now, we’ll be in
> a much better place on the other side.
>
> — Ron
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230829/b8db15e0/attachment-0001.htm>