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
