All Packages from mucode.abstractions.* to mucode.util.*

Home >> All

•

• mucode: Javadoc index of package mucode.

Package Samples:

• mucode.abstractions
• mucode.util

Classes:

• ClassInspector: Utilities for retrieving information about the classes that are declared and referenced by a given class, thus allowing to determine its class closure. java.lang.Class provides methods that enable reflection and allow to retrieve information about a class object. Nevertheless, some of the methods are only defined but not implemented in JDK 1.1. This is the case of Class.getDeclaredClasses() > Class.getDeclaredClasses() 55 , that retrieves the set of types that are declared by the class it operates on. A class C' is declared by a class C if it is either: the class of a field declared by C , or the ...
• Group: The group is the unit of mobility provided by µ Code. A group provides the programmer with a container that can be filled arbitrarily with classes and objects, and shipped altogether to another µ Server. No constructor is provided for this class. Instead, the creation of a group must be requested to a specific µ Server, by invoking the method createGroup 55 . This ties a group to a specific µ Server, which defines the context where classes are resolved. Thus, for instance, let us assume that a group g has been created by invoking createGroup on a µ Server s . If a ...
• MuAgent: Provides a "mobile agent" abstraction. Migration is obtained by invoking the go 55 method as in myAgent.go("myhost:2000") . After migration, the agent is removed from the source host. Only weak mobility is provided, in that the execution state of the agent (i.e., its instruction pointer and call stack) is not preserved across migration---a limitation coming from the Java VM. However, the data state of the agent, i.e., the values of its object fields, is preserved. The agent can determine, from time to time, which classes should be shipped at destination along with it. This is accomplished by the ...
• MuClassLoader: Redefines class loading according to the policy of µ Code. When a class name C needs to be resolved during the execution of a thread t , the class loader that gets invoked is the one that was used to load t 's class, according to the rules stated by the Java specification. If the t has been created with a class that comes from a group, the class loader will be an instance of MuClassLoader . Otherwise, it will be the system class loader. The class loading policy implemented by MuClassLoader is as follows. Assuming t is executing within a µ Server S , the class loader will perform the ...
• ClassSpace: Defines a name space for classes loaded by a µ Server. After a group has been handled, possibly spawning one or more threads, the corresponding classes are kept into a private class space . The presence of a separate class space avoids name clashes among classes belonging to different groups, and guarantees that a mobile thread actually uses the classes shipped with its group rather than some other class with the same name already present on the µ Server. However, µ Code provides operations that enable a thread to "publish" classes in the shared class space associated with a µ ...
• Launcher: This class simplifies the task of passing command line parameteres from an application to a µ Server embedded in it. It also provides a facilities for starting a µ Server directly from the command line. The class is essentially a wrapper around a µ Server. The method parseArgs 55 allows parsing of command line arguments. Command line options start with a dash ( "-" ). The set of recognized options is the same as the set of µ Server properties, defined in mucode.MuConstants and explained in MuServer.properties > MuServer.properties 55 . An additional option -propertyfile ...
• Relocator: This class provides some abstractions to deal with the relocation of classes and threads at a higher level than the one enabled by the primitives provided in the core mucode package. Under the hood, Relocator objects still rely on a µ Server, that is indeed specified at creation time (and can later be changed). The operations provided by Relocator are represented in terms of group shipping and handling. In fact, the semantics of the operations in Relocator is partly implemented in this class (that manages the creation and shipping of groups) and partly by the RelocationHandler class (that ...
• MuServer: Provides an abstraction of the run-time support needed to receive and/or execute mobile code. A MuServer object does not enable per se the handling of incoming mobile code, rather they provide only the capability to ship mobile code to other µ Servers. In order to accept incoming mobile code, a thread listening for incoming groups must be explicitly started in the µ Server by calling the boot() 55 method. This choice minimizes the overhead introduced by the run-time support, wasting a thread only when really needed. Multiple servers can be started on the same Java VM or on different ...
• GroupHandler: Classes implementing this interface can access a group before its content is installed on the receiving µ Server. A requirement for the classes implementing this interface is that they must: be declared as public , and implement a public, parameterless constructor.
• MuCodeException: The superclass of every exception thrown by this package. Instances of this class are also used to wrap lower-level exceptions (called internal exceptions ) generated by the implementation, e.g., IOExceptionException or ClassNotFoundException .
• RelocationHandler: The group handler for all the operations provided by the Relocator class.
• DuplicateClassException: Thrown upon an attempt to insert a class in a class space where a class with the same name already exists.
• ClosureConstants: Constants identifying different kinds of class closure.
• MuConstants: Package constants.
• Header
• MuObjectInputStream

Home | Contact Us | Privacy Policy | Terms of Service