You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We will add a new, non-standard, NPM module called "trireme-support". This module will include a function called "loadJars" that allows the user to specify an array of file names of JAR files.
Internally, this module will use a native module (loaded via process.binding) called "trireme-native-support". This way, non-Trireme users can still import "trireme-support", which will support a way to tell if code is running on Trireme.
With this solution, instead of writing the Java module and putting it on the system classpath as they are doing now, the user can include the JAR file from Node.js code.
When "loadJar" is called, the following will happen:
Trireme will create a new classloader. (Each invocation of "loadJars" will create a new classloader.) The classloader will not be shared with any other invocations of "loadJar" within the same Node.js application or with any other Node.js application on the same JVM.
Trireme will inspect the argument to "loadJars". If it is a single string, then it will attempt to open the JAR file described by the string. If it is an array of strings, then it will open each and create a classloader that includes all the JAR files. An exception will be thrown if any file cannot be opened.
While opening JAR files, Trireme will apply the same "Sandbox" policy that it applies to all other files.
Once the classloader is created, Trireme will use the ServiceLoader pattern (java.util.ServiceLoader) to load Node.js modules implemented using the "NodeInterface" interface from Trireme. (This is the existing mechanism for extending Trireme with Java code and is already in use within Trireme and Edge.)
After "loadJar" has completed, the modules will not be loaded, but they will be available in the Node.js namespace for loading. The user can now load them using "require" in the same manner they would load a Java module that was placed on the system classpath.
Once loaded, the jars do not run in any particular security manager (other than the system security manager).
The text was updated successfully, but these errors were encountered:
We will add a new, non-standard, NPM module called "trireme-support". This module will include a function called "loadJars" that allows the user to specify an array of file names of JAR files.
Internally, this module will use a native module (loaded via process.binding) called "trireme-native-support". This way, non-Trireme users can still import "trireme-support", which will support a way to tell if code is running on Trireme.
With this solution, instead of writing the Java module and putting it on the system classpath as they are doing now, the user can include the JAR file from Node.js code.
When "loadJar" is called, the following will happen:
Trireme will create a new classloader. (Each invocation of "loadJars" will create a new classloader.) The classloader will not be shared with any other invocations of "loadJar" within the same Node.js application or with any other Node.js application on the same JVM.
Trireme will inspect the argument to "loadJars". If it is a single string, then it will attempt to open the JAR file described by the string. If it is an array of strings, then it will open each and create a classloader that includes all the JAR files. An exception will be thrown if any file cannot be opened.
While opening JAR files, Trireme will apply the same "Sandbox" policy that it applies to all other files.
Once the classloader is created, Trireme will use the ServiceLoader pattern (java.util.ServiceLoader) to load Node.js modules implemented using the "NodeInterface" interface from Trireme. (This is the existing mechanism for extending Trireme with Java code and is already in use within Trireme and Edge.)
After "loadJar" has completed, the modules will not be loaded, but they will be available in the Node.js namespace for loading. The user can now load them using "require" in the same manner they would load a Java module that was placed on the system classpath.
Once loaded, the jars do not run in any particular security manager (other than the system security manager).
The text was updated successfully, but these errors were encountered: