JEP 411: Missing use-case: user functions in an RDBMS

[Chapman Flack]

On 05/28/21 10:03, Chapman Flack wrote:
> I still think it would be highly desirable for the JDK itself to
> adopt some such mechanism, if it can be made sufficiently non-cumbersome,
> and perhaps limited just to file operations

... and Process / ProcessHandle operations ....


I am trying to enumerate, in my head, how many kinds of operations
there really needs to be some API for applying filters to, in a post-SM,
JPMS encapsulated world.

As far as effects a JVM can have on the observable outside world,
there are: native actions (and --enable-native-access), file operations
(and there is -Djava.nio.file.spi.DefaultFileSystemProvider), socket
operations (and there are SocketFactories, though how to set them is
undocumented and might fall victim to JEP 403), and process operations
(how to filter those? only instrumentation?).

Am I missing some?

It seems to me that a lot of the complexity of the permission model
in the pre-JPMS-encapsulation world involved protecting actions that
you might not otherwise care about except that they were all needed
to make "self-protecting managers" possible, without which the manager
could be defeated and then allow actions you'd care about.

If JPMS encapsulation can take over most of that busy-work, does that
perhaps mean the set of JDK operations that an application might
want/need to intercept and filter shrinks down to some concisely-enumerable
set of operations that have external effects?

I am not sure ... thinking aloud.

Regards,
-Chap