Symbol/Dependency Resolution
Problem Statement:
Scripts are executed within a language specific script runtime (also called
a script engine). We need to define the features of this runtime container
with regard to symbol resolution and dealing with symbol conflicts.
Use Case:
- User loads a document that contains two java scripts, one was written with
a dependency on version x of class c, the other was written with a dependency
on version y of the same class.
Analysis:
Language independence?
Different languages load symbols and resolve dependencies in very different
ways so it may not be possible to define a language independent way of dealing
with issues like name clashes. The investigations for Java outlined below
may provide some insight into how the problem can be solved in other languages.
How do we load different versions of the same class in the Java ScriptEngine?
Once a class has been loaded by the JVM's default system classloader it cannot
be unloaded, so we will not be able to load a different version of a class
with the same fully qualified name if we use the system classloader.
One solution would be to start a separate JVM for each script run, but this
would be very resource intensive.
A better solution is to mimic what servlet engines like Jakarta Tomcat do,
which is to implement our own classloader which is used to load all script
specific classes. If each script thread uses its own instance or our class
loader concurrent script threads can use different versions of a class with
the same name. When the script completes and it's thread is reaped, the classloader
will be garbage collected and all the classes it has loaded are unloaded.
How do script developers specify script specific classpaths?
By default the script thread's classloader should load classes in the script
archive (.sar) file. The script specific classpath could then be augmented
by a list of jar files stored in the Class-Path header of the script archive's
manifest file.
What about dependencies on particular versions of classes?
The Java Package Versioning Specification allows version information to be
placed in the manifest file of a jar file. It should be possible for a script
developer to specify what version of a jar file their script depends on.
The Java ScriptEngine would be able to check for the correct version of a
jar dependency when searching for jar files. It should search for jar files
first in the script archive, then in the document, and finally at the application
level in a ScriptEngine classpath. If it finds the necessary version of the
jar file it would then add that jar to the script specific classloader's
classpath.
How do we deal with conflicts when they occur?
The Java ScriptEngine would throw an exception which would filter up to the
user as an error dialog.