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.