Questions w.r.t. plans to restrict the FFM API

[Mike Hearn]

Thanks! OK, so let's zoom in on two of the issues here:

1. The exact meaning of safety in the post-SM world.

2. The usability benefits of a mechanism different to module visibility.

I suspected we might end up discussing the definition of safety, hence
the opening discourse on it. I'm still struggling a bit to wrap my
head around what this concept means now. The issue of APIs that change
final fields feels orthogonal to the other aspects of safety (security
and "nice" crashes). You can change final fields from both Java and
JNI today and whilst it restricts optimizations, going slower or
faster isn't something I think most people associate with the notion
of safety. Or if anything people would think slower=safer and
faster=less safe by analogy to the real world, but here the meaning is
inverted.

The other reason it feels orthogonal is that this is an API design
issue very specific to Java as it stands in 2021, and it's really
primarily a HotSpot developer concern rather than a Java developer
concern (modulo that everyone loves performance). Safety feels like
it's meant to be a runtime design principle that could also apply to
V8 or .NET. If a new Java release allows truly final fields then this
aspect of safety would disappear, but a truly general principle
shouldn't change in major ways from one version to the next. Perhaps
I'm over-focusing on final fields, but I'm not sure how to generalize
this appropriately because I'm not totally sure what the connections
are between the aspects. A clear definition of safety and the
justification for it for each group of stakeholders would be a really
good thing to have.

OK, re: usability.

> The places where opt-in will occur will be the "applications" which
> package one or more libraries using FFM. These applications will already
> come with launchers, or will be generated via tools like `jpackage`.

Yes, I understand that. My point is that developers are users too. If
I am writing an app and add a new top level library dependency that
pulls in another 4 levels of libraries (quite possible in today's
ecosystem), then if the library author at the bottom of that stack
wants to start using FFM then they must do a new release that adds to
their readme "you now need --enable-native-access on JDK >X for this
module to work". And then because there's no mechanism to propagate
this, the authors of the next level up must do the same thing, and so
on, until I upgrade that top level dependency and hopefully spot the
new warning somehow in the release notes. And then finally the action
is on me to adjust my JVM arguments. This is kind of awkward and a lot
of work for everyone in the chain. Whilst the ultimate non-technical
end users don't have to do anything, developers-as-library-users
definitely do.

> Maybe it will be possible, for a module that is "inside the bubble" to
> grant (reflectively) native access to other modules.

This is certainly a solution, although it complicates app development
and the goal is to simplify it.

> * you don't see the flipside; consider now an application which supports
> plugins but which, for whatever reason, _doesn't want_ plugins to access
> native code. The proposed solution gives you a way to do that (if required).

I did consider that flip side but, as mentioned, I can't think of a
situation in which anyone will actually do this.

Again, this comes back to the definition of safety. With an IDE or
build system, the exact nature of HotSpot's optimizations aren't
something that directly affects people. Debugging experience does
affect them so they might care about that, but in which circumstances
would an IDE developer want to stop plugins accessing native code? The
plugin cannot be sandboxed anymore and that's what users would really
value. So restricting native code but not java.io.File feels a bit
pointless - it could be helpful if for some reason the userbase keeps
segfaulting their IDE with terrible native plugins and we want a
REALLY big hammer to stop that happening, at the risk of upsetting
users whose plugins are now broken. But that'd be a very rare
situation. Java apps could use the SecurityManager to restrict JNI in
the same way until now but nobody ever did.

W.R.T. separate modules, yes it's true, splitting the modules
introduces discoverability problems and makes the API worse. So maybe
this is suggesting there's a need for a more heavily designed
mechanism. The JVM now has quite a lot of ad-hoc flags that act as
"yes I know what I'm doing" markers:

* Incubation
* Opening modules
* Native access

Gradle and Kotlin have similar mechanisms now too. All of these have
the same flavour: "you don't want me to do something but I definitely
want to do it, so here's a flag to make you get out of the way". It
feels like there's the potential to unify these, perhaps with
solutions to the module refactoring, dependency chain and plugin
loading problems.