The Jamboo kernel is basically an individual class that implements the singleton pattern so it is accessible from anywhere in the application. It is possible to query and request a reference to a module by providing a unique string identifier.

The Jamboo kernel provides the backbone for vrtp with its run-time dynamic plug-in architecture where modules are loaded/unloaded on demand. There are three phases in the Jamboo cycle:

• Start-up. During this period the Jamboo kernel loads the required modules by obtaining the class code from local or remote storage. A configuration file provides the initial settings.
• Run-time. During this period the Jamboo kernel changes the set of modules dynamically upon request from the various modules.
• Shut-down. The Jamboo goes through the process of shutting down all the modules and unloading them from memory.

The Jamboo kernel can be used both within the context of either an applet or an application:

• Application. This approach provides more flexibility but the user must explicitly use the java command line to initiate the Jamboo kernel. The command line is as follows, where the filename is optional:

A generic application and applet implementation are provided to demonstrate how to use and setup Jamboo.

The Jamboo kernel receives a configuration file that may correspond to a vrtp session. The Configuration class is responsible for parsing the configuration file and setup the Jamboo kernel appropriately.

The Configuration class has associated to it a configuration file with several sections that are separated by section headers, corresponding to a single line. Each line has the following format:

The ‘@’, which may be another specified character, determines the start of a section, followed by a string that not only identifies the section, but also indicates what SectionConfigureHandler to use. These handles are registered at the Configuration class, doing the actual context specific configuration when called upon. The invocation of a SectionConfigureHandler is possible by supplying their identifier (SectionName) contained in the section header.

How each section is formatted depends upon the implementation of the SectionConfigureHandle that implements the parsing and execution of the settings.

The Configuration class is subclassed to reflect the particularities of applications by constructing the set of SectionConfigureHandlers to use. In the case of Jamboo, the reference implementation JambooConfiguration has the following handlers:

• ModuleConfigureHandler.

1. ModuleConfigureHandler

The ModuleConfigureHandler considers each line corresponds to a Module with the following format:

With the exception of the ModuleName all the remainder parameters are optional, however the ModuleInitialisation has the constraint of succeeding the ModuleURL parameter. Each parameter is explained as follows:

• ModuleName. This consists on the identifier of the module within the Jamboo kernel. It is by means of this identifier that grants accessibility from other modules.
• ModuleURL. This is an optional parameter and its absence indicates that the module class resides in the same directory as the Jamboo class and no initialisation parameter is required. Should the module class reside elsewhere then a string delimited by inverted commas "" should indicate its location weather local or remote. When the location is remote the string may be suffixed with the protocol to be used to retrieve the class file.
• ModuleInitialisation. This is an optional field, however its existence implies the precedence of a ModuleURL parameter even it is an empty string. This parameter may consist of a simple initialisation string or the name of a configuration file.

The most important utility class in the Jamboo kernel is the JambooLoader class. It is responsible for not only retrieving the corresponding class files of the Modules, but also instantiating them and linking them in run-time. The ability of instantiating and linking classes in run-time is due to the linking model of the JVM. The JambooLoader merely provides the ability of retrieving the code from anywhere across the network.

The code should take advantage of the URLClassLoader of JDK1.2 but the requirements related to the new security model have not yet been anaylsed, so current implementation is done in JDK1.1. However the port should be straightforward to JDK1.2.

The JambooLoader receives a request for a particular module, by supplying the name of the Module and the corresponding url where the classfiles are located. The JVM handles dependencies automatically by using the same classloader as the initial class.

The JambooLoader takes advantage of the potential provided by the java.net.URL and all the associated classes, such as the URLStreamHandler. Should the developer not be satisfied with the default URLStreamHandlers provided by the JVM then it is always possible to set a new URLStreamHandlerFactory. JambooLoader uses whatever is available, so it is the responsibility of the developer to invoke the URL.setURLStreamHandlerFactory. In the current version, JambooLoader inherits from ClassLoader, the decision to port it to JDK1.2 must be carefully analysed to deem justification.

The extensions (plug-ins) that are to be added to the main core are divided into two categories:

• Modules. The modules are approved extensions that are part and expected to exist within the Bamboo runtime instance.
• Roots. The roots are the plug-ins designed for the application domain. Most likely these would be downloaded from the network if not available locally.

This criterion is used in Bamboo, however it is prone to confusion since a root is a module and vice-versa. Their main difference is purely conceptual. An alternative concept is to consider everything is a module from the start and that there are several kinds with specific characteristics. The inheritance and implement mechanism of java would allow combining in a subclassed module several different characteristics. Therefore the main types of modules available are as follows:

• Module. This class is abstract and enforces the implementation by subclasses of 4 basic methods: initialise; activate; deactivate; shutdown. The initialise should be invoked at the genesis of the module, just as the shutdown should be invoked at the termination of the module. The activate/deactivate are the same operation but opposite effects. The Jamboo kernel invokes these operations when loading and unloading a module.
• ModuleManager. This is a Module that manages other modules. The Jamboo kernel is a subclass of the ModuleManager.
• ModuleReactor. This Module is a subclass of the ModuleManager but implements the reactor pattern [X], thus even though the managed Modules are not Runnable, in effect it would be as if they were.
• Runnable. This interface is readily provided by the JDK, however, when combined with any of the above, the Module becomes concurrent and asynchronous.

Naturally the Jamboo can only make certain assumptions about what should be the methods to be supported. Therefore the concept of adapters should be applied, delegating the actual class decision to the developer rather then trying to foresee the only way of doing things.

The objective of Jamboo is not a platform but a simple means of dynamically loading and unloading modules in run-time. It requires a protocol to be managed by the application to manage Jamboo. A similar analogy is the Thread class, it just runs provides some functionality but it is up to the developer what to do with it.

The class diagram below, portraits all the classes of the Jamboo package. The current version may be considered as version 0.0, although it is not a release since some work needs to be done such as:

• Include proper exception classes to convey more significant information.
• Implement the reactor pattern in the ModuleReactor (only class that is not completed).
• Do javadoc comments in the code (code is comprehensible because of coding style).
• The implementation of the GenericJambooApplet
• Port to JDK1.2

The current implementation of Jamboo still requires additional development to attain a state suitable for release however it works, proving the concept.