Description
Feature request
Is your feature request related to a problem? Please describe.
Espresso uses the Java classes and native libraries from it's --java.JavaHome, it uses the IO implementation provided there.
Having a guest Java filesystem for both java.io and java.nio backed by the Truffle/polyglot VFS API would allow to sandbox IO within an Espresso context.
Describe the solution you'd like.
An option to enable and replace the default OpenJDK IO classes by a custom implementation backed by the Truffle VFS e.g. something like --java.IO=truffle.
Describe who do you think will benefit the most.
Embedders of Espresso and developers trying to overcome the SecurityManager deprecation.
Describe alternatives you've considered.
- Using the guest Security Manager (it works, but is being deprecated/removed soon).
- Hooking a few native methods for the vanilla Java classes (has different implementations per platform + breaking changes since native methods are usualy not part of the API).
- Implement a Java filesystem (legacy java.io and java.nio) that is Truffle aware, with some substitutions/instrinsics on the Espresso, all written in Java.
The result would be to have TruffleFileSystem/TruffleFileSystemProvider/TrufflePath instead of UnixFileSystem/UnixFileSystemProvider/UnixPath as the default implementation, similar on other platforms.
Additional context.
Is also important in this mode (Truffle IO) mostly used by embedders to block the default Java classes to be used/loaded.
Native libraries are also a concern, since cannot be dlopen-ed from memory.
The same idea applies for sockets but there's no Truffle socket API yet.
Express whether you'd like to help contributing this feature
Internally tracked as GR-38920.
If you'd like to contribute, please read the contribution guide.