The commitment to Java excludes the direct support for other implementation solutions such as DLLs amongst others. However their inclusion involves building a wrapper to the proposed interface and resorting to the JNI to have access to the native solutions. This approach allows the wide community of computer graphics that extensively use other languages to take advantage of Jamboo.

Some of the following ideas may be outdated or completely naïve but they were based on the available documentation of Bamboo and the current implementation release. The ideas will be presented based on the interpretation of the author, thus fallible. It is hoped the initiative to start a parallel solution that will promote the emergence of clear documentation to support the design and provide guidelines for the implementation.

The main kernel would be basically an individual class (bbmain) but implementing the singleton pattern so it would be accessible from anywhere in the application. Therefore for convenience reasons the class would be referenced as Jamboo. It is possible for any module to query and request a reference to another module by providing an identifier (by default the name of the corresponding class).

The Jamboo class would provide support for applet and application:

• Applet. It is possible to include within an HTML page, liberating the user from any configuration hassles and worries. The applet would automatically start and all the configuration settings would be provided by a series of PARAM.
• Application. This approach provides more flexibility but the user must explicitly use the java command line to initiate the Jamboo kernel. Most likely the command line includes a filename that includes all the configuration settings, which the user (or developer) should have properly formatted.

At the moment it is thought to have both solutions as separate alternatives, although it is possible to combine both. The implementation of both solutions only differs at setup time due to the differences in the framework of applets and applications.

The Jamboo kernel receives a configuration file that may correspond to a vrtp session. This file indicates the required modules to be present at load time and others that would become necessary. Along with the identification of modules and their respective initialisation strings, the file indicates possible locations to find the code, excluding the default ones (system and local path). This facilitates the job of the classloader(s) that reside in Jamboo for the purpose of loading dynamically classes, initialising and executing them.

The default behaviour of a classloader will be to search the system (local host environment), the current path (.) and then download the code remotely. The security policy mechanism of JDK1.2 provide useful features to support trust. It is worthwhile to point out that classloaders have dependencies so this is a functionality inherent to Java.

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.

Much of the work being done on the modules while necessary in the current implementation becomes somewhat unnecessary in Java since the JDK supports a rich set of functionality, which combined with the extensions produces a solution VERY hard to excel. In addition to a rich set of functionality it is assumed that most platforms have a JVM.

From an implementation perspective all are viewed as modules and considering the dynamic nature of Jamboo it is the responsibility of whoever does the configuration file to ensure that all the necessary Modules are present to start. The other modules that are acquired after startup may correspond to roots, but the distinction between both is purely conceptual.

It is clear that modules are not classes to be instantiated but rather be subclassed. An alternative is for the module to be an interface to allow a developer to subclass another class while implementing the required interface for Jamboo. Both approaches have their advantages and disadvantages, but only with implementation will it becomes clear which will be adopted. From a design perspective the best solution would be to provide an interface and probably a GenericModule class that implements that interface and demonstrates the required implementation. This approach could be the best decision, since it also allows more advanced developers to just implement the interface.

There exist two main types of modules:

• Active. These modules not only implement the Module interface but also implement the Runnable interface (or inherit Thread). The important issue is that these modules run concurrently from Jamboo and have the run method defined. We may enforce others to oblige cleaning up for example.
• Inactive. These modules are passive, meaning that they run within a dedicated thread that goes through the existing modules executing a particular method. Now the necessary support for this may either be embedded within Jamboo main class or there could exist a dedicated class for that purpose. The latter decision seems the most appropriate.

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.