Overview of JUMP system The JUMP executive is a modular system designed to perform a set of system activities. These system activities might include traditional AMS tasks such as launching new apps, controlling application lifecycle, orchestrating window management, and performing download and installation of content. Other activities might include device management tasks, providing services to other JVM containers, holding device-global state, interacting with the hardware and OS to get system events, and communicating asynchronous events to individual containers.

The JUMP executive is composed of distinct modules conforming to a {@link com.sun.jump.module.JUMPModule} interface. Each module implementation is specified using a Java interface or abstract class that implements or extends {@link com.sun.jump.module.JUMPModule}. This Java interface or abstract class acts as a service contract between modules. There is tpyically a local interface for use between modules inside the same process, and a remote interface for use when modules end up in separate processes.

This type of modularity allows flexibility in implementation:

JUMP modules

When the executive starts up, it loads a list of module factories, calling {@link com.sun.jump.module.JUMPModuleFactory#load} on each one. Module factories can implement this method to perform initialization activities. The list of module factories can be declaratively specified in a file. Alternatively, a subclass of {@link com.sun.jump.executive.JUMPExecutive} can override its initialize() method to hard-code a set of module factories to load.

Within a process, modules can be discovered using the appropriate factory for the module. For example:

JUMPLifeCycleModuleFactory lifecycleFactory = 
    JUMPLifeCycleModuleFactory.getInstance();
JUMPLifeCycleModule lmod = lifecycleFactory.getModule();
// ... Use of the lifecycle module follows

There is a set of abstractions inside the JUMP executive that are designed to apply to all modules. These cover the representation of isolated JVM instances managed by the executive, and the core communication mechanisms used to access them.

JUMP isolates

Isolated JVM instances are called JUMP isolates. A {@link com.sun.jump.executive.JUMPIsolateProxy} object encapsulates the state of a running isolate and returns an instance of a {@link com.sun.jump.executive.JUMPApplicationProxy} that can be used to control its lifecycle of a corresponding {@link com.sun.jump.common.JUMPApplication} running inside the active isolate. Each JUMP isolate contains one to many {@link com.sun.jump.common.JUMPApplication} objects. The JUMP executive can affect application lifecycle using the {@link com.sun.jump.executive.JUMPApplicationProxy#pauseApp} and {@link com.sun.jump.executive.JUMPApplicationProxy#resumeApp} methods. The JUMP isolate can also request lifecycle changes from the JUMP executive. The isolate factory (interface {@link com.sun.jump.executive.JUMPIsolateFactory} is used to perform isolate management operations. It can create new isolates, and manage currently running isolates.

Each JUMP isolate gets a set of abstractions that allow it to use the JUMP system. These abstractions can be found in package {@link com.sun.jump.isolate.jvmprocess}. The {@link com.sun.jump.isolate.jvmprocess.JUMPIsolateProcess} class represents a JUMP isolate that is implemented using a JVM process. It hosts common JUMP infrastructure, and also contains the application running within the container. The {@link com.sun.jump.isolate.jvmprocess.JUMPAppContainer} object is responsible for launching the application class and handles all the JUMP Isolate related functionality, translating the JUMP environment to a {@link com.sun.jump.common.JUMPAppModel} specific view.

Communication between executive and isolates

Here's how a sample request-response sequence occurs. In this case an isolate is sending a message to the executive process:

static boolean requestResponse() {
    JUMPIsolateProcess myProc = JUMPIsolateProcess.getInstance();
    JUMPProcessProxy execProc = myProc.getExecutiveProcess();
    String mType = "message/test";

    JUMPRequest r = new JUMPRequest(mType, new String[] {"a", "b"});
    JUMPOutgoingMessage m = r.toMessage(myProc);

    JUMPMessage responseMessage;
    try {
        responseMessage = execProc.sendMessage(m, 0L);
    } catch (Exception e) {
        e.printStackTrace();
        return false;
    }
    JUMPResponse response = JUMPResponse.fromMessage(responseMessage);
    if (response.getCommandId().equals(JUMPResponse.ID_SUCCESS)) {
        return true;
    } else if (response.getCommandId().equals(JUMPResponse.ID_FAILURE)) {
        return false;
    } else {
        // Unknown ID
        return false;
    }
}

The types of request commands that can be composed can be found in {@link com.sun.jump.command} package, and the types of responses can be found in {@link com.sun.jump.command.JUMPResponse}.

Remote access to JUMP modules

From an isolate, a JUMP module can be accessed using a remote interface, using the remote service interface as a key. For example:

import com.sun.jump.module.lifecycle.remote.JUMPLifeCycleModuleRemote;

String remoteLifecyleInterface = JUMPLifeCycleModuleRemote.class.getName();
java.rmi.Remote mod =
    JUMPIsolateProcess.getRemoteService(remoteLifecycleInterface);
JUMPLifeCycleModuleRemote rlifecycle = (JUMPLifeCycleModuleRemote)mod;
// ... Remote use of the lifecycle module follows

All interfaces com.sun.jump.module.*.remote.* are packaged for visibility in launched isolates as well as the executive, to make sure clients of remote interfaces see a consistent view.

Known modules

What follows is a list of modules, with local and remote interfaces:
Module nameLocal interfacesRemote interfaces
JUMP isolate lifecyle module {@link com.sun.jump.module.lifecycle} {@link com.sun.jump.module.lifecycle.remote}