Application Integration
Nicobar can express complex dependencies between modules. Traditional java classloaders are designed to have only one parent, and this makes it hard to model shared modules. Here is a typical java classloader hierarchy.
Given the limitations of traditional java classloaders, classloader D and E cannot share the classes in classloader B (at-least not without duplicating classloaders and flattening the dependency graph).
As described in the Script Modules section, Nicobar modules are backed by classloaders that can have multiple parents. This allows creation of classloader dependency graphs that allow shared modules.
In addition, script modules have powerful filtering capabilities to the set of packages imported from parents, and the set of packages exported from the module to dependents. By default, every module imports all packages from its parents, and exports all packages from itself, and its parents (transitive dependencies).
As the application integrator, if you want to sandbox modules from each other, you can override a module’s ScriptModuleSpec to provide a specific set of import and export paths, or an empty set to prevent anything from being imported or exported. For more information, see ScriptModuleSpec.getModuleImportFilterPaths and ScriptModuleSpec.getModuleExportFilterPaths.
Nicobar by default adds a dependency edge from a module, to all of its compiler plugins, so that the dependent module gets access to the language runtime, both during compilation and during execution.
A default dependency is also added to application’s classloader, filtering the dependency edge to a specific set of application packages, which are provided to the ScriptModuleLoader as it is being built. For more information see, ScriptModuleLoader.Builder.addAppPackages
Nicobar modules can be hot-swapped. Thus, behavior of named modules can be easily changed at runtime. Modules updated in place, are relinked with other classloaders in the graph, and thus hot-swapped seamlessly.