JEP draft: Prepare to Restrict The Use of JNI

[Glavo]

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

The pursuit of integrity is good, but this does not mean that any feature
that is labeled as "breaking integrity" should be thrown into the warning
zone.
FFI is such an important and widely used feature that it deserves to be
treated as a normal feature.

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

Have you surveyed the maintainers and user groups of widely used libraries
in the Java ecosystem that require FFI?
I don't think anyone would be satisfied with such a crude decision.

Glavo

On Tue, Aug 29, 2023 at 6:27 AM 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/88e4ed4e/attachment-0001.htm>