Please send any comments or questions about the API or this FAQ to the JSR-121 expert group's private email alias: jsr-121-comments@jcp.org, or to the public discussion alias at isolate-interest.
The JSR-121 Java Application Isolation API adds multiple application
support to the Java Virtual Machine. Each application, called an "Isolate"
by the API, is given the illusion of running in its own isolated virtual
machine: each application gets its own system properties, its own classpath,
its own static class state, etc. Isolates can be cleanly terminated. Pure
Java mechanisms for application life cycle control and communication are
also provided. The API is flexible enough that VMs can implement it using
the underlying OS process facilities, or the VM can isolate all the separate
applications within a single process.
There are two reasons to create an isolate. First, to isolate the
faults in one application (or a sub-application) from the code that creates
the isolate. Second, to provide a boundary allowing an isolate to be terminated
cleanly.
Assuming a class "HelloWorld" can be found on the default application
classpath:
try {
Isolate i = new Isolate("HelloWorld", null);
i.start();
} catch (IsolateStartupException ise) {
System.err.println(ise);
}
Other than error reporting, this is basically equivalent to the command
line invocation "java HelloWorld".
An aggregate is the set of isolates sharing a common ultimate ancestor.
Any state managed or owned by the host operating system (i.e., not
managed or owned by the JVM) is generally considered aggregate-wide state.
Java-specific state is generally maintained on a per-isolate basis. In
practice this means, for example that each isolate has its own initial
security manager, its own application classpath, its own AWT, etc., as
these are maintained by the JVM. State such as the "current working directory"
or the hostname, etc, are maintained outside the VM and are thus considered
aggregate-level state.
No visible objects can be shared between different isolates as that
would violate the illusion of a VM for each application. Isolates may still
communicate in many ways, but there can be no discernible sharing of objects
between isolates.
No, that would break the illusion of a separate VM for each application.
Application-visible static fields are logically per-isolate. Implementations
may play tricks to share state, but they must preserve the illusion of
per-isolate static fields.
Logically, yes, by virtue of object and static field isolation.
Not portably. Generally, user identity is tracked and managed by
the underlying operating system, and thus cannot be exposed as a per-isolate
property.
Not portably. Generally, the "working directory" is tracked and
managed by the underlying operating system and thus cannot be exposed as
a per-isolate property. Consider using alternatives such as
ResourceBundles
or jar files instead of relying on the immutable current working directory.
Because of the strong separation of isolates. The problems that
plagued Thread.stop
do not apply to isolates because all threads that can access objects or
state that might get damaged will also be stopped. Still, The
halt
method should still be used only as a last resort, after "polite" methods
of shutting down an isolate have stalled or failed, so an application will
leave persistent state (or other state visible outside the isolate) in
a consistent fashion.
That is an implementation decision. The Isolate API certainly allows
multiple isolates to exist in a single underlying OS process. The JSR-121
reference implementation will be a "one-to-one" implementation style with
each user-defined Isolate occupying an OS process. Experimental versions
of "many-to-one" style implementations are in development (watch www.experimentalstuff.com
and the Janos
Project JanosVM for announcements.)
Create a new IsolateMessage
containing the new source for standard input, and then pass that
IsolateMessage
as the appropriate argument to the long
Isolate
constructor.
The application classpath for a new isolate is a system property
(java.class.path) of that isolate. System properties are defined
in the "java.properties" node of the 'context' argument to the
long
Isolate
constructor. So, you must set the "java.properties/java.class.path"
entry in the context:
TransientPreferences p = new TransientPreferences();
p.put("java.properties/java.class.path", "class path");
To execute a jar file in a new isolate (similar to the -jar
option supported by some java commands), the "Main-Class"
attribute must be extracted from the jar's manifest. Additionally, the
jar file must be placed on the class path for the new isolate.
The following example loads and executes "app.jar" in a new isolate. First, the name of the main class is extracted from the jar's manifest:
Second the "java.class.path" property for the new isolate is set with the name of the jar file:String jarFileName = "app.jar"; String mainClassName = new java.util.jar.JarFile(jarFileName) .getManifest() .getMainAttributes() .getValue(java.util.jar.Attributes.Name.MAIN_CLASS);
TransientPreferences p = new TransientPreferences();
p.put("java.properties/java.class.path", jarFileName);
Finally, the isolate is created and started with the main class and the
preferences containing the appropriate classpath:
Isolate jarIsolate = new Isolate(mainClassName, null, p, null); jarIsolate.start(null);
You need to know the name of the main class for javac (in
some systems, for some versions, it may be that "com.sun.tools.javac.Main"
is the right choice.). See "How do I run 'HelloWorld'?" in this
FAQ.
You must have an EventLink to the target isolate, before
the isolate starts. Once the isolate starts, use the IsolateEvent.getStarter()
method on the starting event received on the EventLink.
An isolate can only be made aware of other isolates by creating
those isolates, or by receiving an Isolate object representing
that isolate on a Link. The Expert Group expects implementors
to provide implementation-specific methods for querying the aggregate for
isolates and isolate relationships. We felt this area of the API did not
need to be defined now, because without any real usage, we would probably
have gotten it wrong.
The best way is to wait for a "terminated"
IsolateEvent.
The brute force way is to wait until Isolate.hasTerminated() becomes
true.
All the alternatives we considered are either too weak (they lose
compile-time type checking), or too flexible (the API would structurally
admit too many unsupported types).
The Application Isolation API has been designed with J2ME subsets
in mind. One or more J2ME standards are expected to stem from the J2SE
standard eventually, subject to JCP policies.
Unlike any existing Java I/O mechanism, links allow I/O objects
(such as files, sockets, and links) to be passed between isolates.
RMI can easily be used in addition to links. If there is no requirement
for exchanging low-level I/O objects, then RMI is probably the better choice.
RMI however, cannot support exchange of low-level I/O objects or Isolate
objects between isolates.
Binding of the standard I/O streams happens once, when the isolate
is created. A Link allows more dynamic behavior by allowing applications
to communicate I/O objects later in the life-cycle of an isolate.
To pass a Link to a newly created isolate requires that
the Isolate be created before the Link can be created. Thus the
creation of the
Isolate needs to be separated from start to allow
a Link to the new
Isolate to be passed to the new isolate.
Isolate child = new Isolate(....);
Link linkToChild = Link.newLink(Isolate.currentIsolate(), child);
child.start(new IsolateMessage[] { IsolateMessage.newLinkMessage(linkToChild) });
The Process class is designed for creating and controlling
legacy, non-Java applications, so would prevent the additions made for
construction of Java-specific application creation. Also, using the Process
class makes J2ME API support difficult or impossible.
The semantics of some Runtime and System methods
are changed slightly by the presence of isolates. For example the scope
of the System.exit() method causes the isolate to exit, and not
necessarily the entire aggregate.
Yes, it is.
No. This class is a proposal for another JSR (which covers the NIO
classes more generally). Note that the support for various Channel
types on IsolateMessage
Perhaps we have! Check the isolate-interest
mailing list and archive.
Or, send your question or comment to
jsr-121-comments@jcp.org.