Juggle Your Java with JDistro

Appropriately
enough, running multiple Java applications at once can be akin to
drinking too much coffee in one sitting: You get erratic
results and ultimately crash hard. But having more than one Java
program running can be helpful for development. Java programmer
Guillaume Desnoix wanted such a robust environment, so he created his
own: JDistro.
The 34-year-old software engineer from Compiègne, France
started developing it in January 2002 and presented it publicly
a month later. But he had been tinkering with the idea of a
multitasking Java manager as far back as 1998.

I wanted to run many Java apps at the same time and to remove the
artificial difference between applets, beans, and applications, and
the widget toolkit (AWT, Swing, SWT, LCDui)," says
Desnoix.

The effort to organize Java applications under a
single, desktop environment isn't unique. Gérard Collin, also
34 and from France (Paris), was working on a similar
program,
but he quit developing it and decided to help Desnoix on JDistro
instead. "When I saw JDistro,
after much thought, I concluded it's better to join forces,"
says Collin. He brought two notable contributions from his project:
code that automatically finds Java applications on a computer and
installs it for JDistro to use, and a "catalog"--a
database that organizes status information about Java applications
running under JDistro.

JDistro in Action

The ability of JDistro to run multiple Java apps simultaneously is depicted
in Figure 1.

Figure 1. JDistro is shown running three Java apps at once: an IDE
(CodeGuide 7.0), a text editor (jEdit 4.2), and an RSS aggregator (HotSheet).
Note that a terminal session (jsh) is open. (Click on thumbnail for full-size
version.)

Interview with the Developers

Collin and Desnoix spoke with us about the challenges associated
with building a manager that brings the buzz of
Java without the crash.

Howard Wen: What is
the current status of JDistro?

Guillaume
Desnoix: The feature set is quite rich. For this reason, modules
have a different level of maturity, from alpha to quite stable.
JDistro is still a work in
progress; we plan to release version 1.0 in 2005. But it is
already usable today.

Gérard Collin: Many Java
applications can run in it without modifications. Of course, some
(especially the big ones) do not, because they use programming tricks
that are incompatible with JDistro.

In
order to run more than one application under the same JVM, you need
to heavily modify some core Java classes. For example, threads,
classloaders, and JFrames
are not handled exactly like the standard ones, and some applications
simply don't appreciate that.

JDistro
can run applets, JNLP applications, installed applications on the
hard drive, and even J2ME apps, all on a consistent desktop.

We
can operate in three modes now: one where all applications are under
the same window, which means we must modify on-the-fly JFrames
to JInternalFrames; another,
where all applications still keep their own windows; and a silent
mode, where JDistro can run
all applications through a telnet interface.

HW: Why
develop an entire operating system under Java? What are the practical
benefits of such a thing?

Desnoix: I don't consider
JDistro an operating system,
even if it has similar features. Instead, I call it a "shared
runtime and desktop." The main problem with Sun's current JRE is
its high usage of memory. By sharing the JVM, you can launch more than
one application at the same time.

Collin: This is one
of the main benefits of JDistro:
it's an easy way to run many Java applications on a desktop with
icons, a file explorer, application installation from the Web,
MIME-type handling, etc. JDistro
is only a desktop. It's not an operating system. It still needs
Linux, Windows, or Mac OS X behind it, with a standard JVM.

HW:
Was JDistro inspired by any
other program?

Desnoix: Not really, but I knew of Echidna
and [Collin's] jsh. What [motivated] me to start this project
was the possibility to transform JFrames
into JInternalFrames. As far
as I know, no other software does that. Some projects have shown the
way, like Michael Emmel's work on Swing peers for AWT, Jesktop
for the idea of a Swing desktop, and JavaURL
and Netx
for a full JNLP client.

HW:
As you may know, there are plans by IBM
and Apple
to implement a form of JVM sharing, which may be included in J2SE
6.0.
What are your thoughts about IBM's and Apple's approaches?

Desnoix:
There are many different levels of sharing. Apple JRE 1.4 and Sun JRE
5.0 already have some kind of sharing, but it's quite limited. Projects at
IBM and Sun want to extend the sharing to all of the constant static
data. JDistro is different: we call it a "shared JVM." This
is a less robust approach, but it has some advantages: it's lighter,
it's faster, there's only one JVM to manage, and it has better integration. Robustness is
very important, so the approach of the major vendors is good. But
applets and servlets have shown that it is also possible to run
multiple Java apps in the same container.

Collin:
IBM's and Apple's approaches are different from JDistro's. They try to
spare memory by having a pool of classes common to all JVMs running in
the same computer. They avoid, at all cost, communication between
applications running in different JVMs, because they want to be 100 percent
compatible with them.

JDistro tries to make all of the applications run in the same JVM. It
dynamically modifies the bytecode of the applications so that they
behave correctly together. I'm sure we can achieve almost 100 percent
compatibility, but with some tweaks in the core Java classes. They must
be modified by Sun to support this.

Moreover, we need to allow communication between, at least, JDistro and
the running applications, in order to display them in the desktop, call
them when needed, change their look and feel, etc.

HW: In
some ways, the idea of JDistro is similar to regular application
servers. Did you take your inspiration for JDistro from these,
implementing similar ideas, or is JDistro actually different in some
interesting, technical way that you would like to point out to other
Java developers?

Desnoix: The
idea is more about the origin of Java: applets. So we may refer to
HotJava as a container written in Java for Java applications.
Application servers are different: they provide important services
and manage components. JDistro does not provide an API, and just
controls the components.

HW:
Does JDistro use code or
libraries that you did not originally develop? Why were these
chosen?

Desnoix: Yes and no. A lot of the libraries are
[from other projects] I wrote. Among those I didn't write are the ACME
image encoder, GNU regexp, GNU getopt,
and ObjectWeb
ASM.
The first two [will] be removed soon and replaced by the
corresponding APIs of the JRE.

Collin: Guillaume is an
"I-can-do-it-better-myself" developer. After looking at
existing libraries, most of the time he [decided to] do it himself.
I'm quite impressed by what he can do.

HW: What unique
program technologies, if any, have been specifically created for
JDistro?

Desnoix:
The raw bytecode replacement, the
transformation of the top-level components, the transparent virtual
filesystem, and the delegation of the system classloader
are, as far as I know, unique.

Collin:
Our classloader modifies the bytecode of the classes it loads
and replaces, for example, all calls to java.lang.System into
our own com/JDistro/WSys. This way, we can change a lot of
things in the application [such as] morphing JFrame
into KFrame, [and] insert our
own File classes.

Desnoix: Support for AWT is implemented using Swing peers. It is not finished, but applications like ImageJ and Art of Illusion already run well. While not yet included in the distribution, support for SWT-based Java applications and X11-based native applications are provided by Christopher Decker's port and JCraft WeirdX X server, respectively. They will be part of the 1.0 release.

HW:
What are the technical limitations of JDistro,
thus far?

Desnoix: [Incompatibilities with] the old event
system [in] Java 1.0.2 still used by some applets, and the recursive
call of getParent() used by some applications to find their
top-level windows. We also have problems with URL protocols and
EventQueues defined by an application. The first one is due to
the way you specify your handler (the system property
java.protocol.handler.pkgs). The second should be solved by replacing their superclasses.

Collin:
The Java runtime and the Java classes library have really been
designed to run only one application [at a time]. Things like the
System.exit () that stops the JVM, the
System.setSecurityManager (), the System class loader,
and the global URLStreamHandler are really annoying to us. Sun
should make modifications to its Java system libraries, so that we
would have some kind of an Application object per application,
handling all of these global things.

HW: What have been the biggest technical challenges
you have faced in writing JDistro?

Collin:
The biggest, in my opinion, is making many applications with
extremely different behaviors work under JDistro.

Desnoix:
Almost every feature is a challenge when you start to code it. The
biggest one is maybe the classloaders and, in particular, the system
classloader implemented by Gerard.

HW: Could the code for
JDistro be reused to develop
other types of programs?

Desnoix: The core of JDistro
can not be really reused, except for re-implementing something
similar. On the other hand, the libraries could be reused--and, in
fact, are used--in other projects. Some modules could probably be
adapted quite easily, like the support for MIDlets or JNLP.

Collin:
JDistro has been separated into many parts, but lots of them
are dependent upon each other, and they all are dependent to our core
framework, which is quite big now. So I think it would be quite
difficult for someone to extract a part and use it in its own
program.

In fact, we would make any changes to any part so
that they can be reused elsewhere, as long as it's GPL. We believe in
the open source movement, and would be happy to cooperate with
anyone.

Desnoix: I disagree--when there are dependencies, they could be removed quite easily. Refactoring is on the way. Gerard, what do you think?

Collin: Refactoring is on the way, but it's not our priority. I would say: if someone asks us to separate, we can do it then.

HW: What features do you plan to add to future
versions of JDistro?

Collin:
What we would like to do:

1. Improve the "catalog"
(the list of online applications for JDistro)
with the ability to modify existing applications, to log in and out,
insert screenshots, etc. I would like that the catalog be the place
you go when you search for a Java application, even if it's not for
JDistro.

2. Make tools
that would communicate with the catalog via XML, so that you can use
a decent user interface to add new applications, modify them, rate
them, etc. The idea is that if you have installed an application
under JDistro that pleases
you, you can add it into the catalog using a wizard.

3. When the
Java operating system jnode
is ready, we would like JDistro
to be their desktop.

4. Transparent support for Java
applications that don't run in JDistro.
They would run in another JVM, but we would need only the JDistro
desktop for all Java applications.

HW: What would you like
others to notice most about JDistro?

Desnoix:
That you can use the shared runtime without the desktop--if you
really want to use your native desktop. Or, you can remove your
native desktop and just use JDistro.
Also, JDistro is a portable
desktop, so it runs the same on every OS.

HW: If somebody
wants to contribute to your project, what skills from them could you
use now?

Desnoix: There is still a lot of work [needed] on
the modules. I would also welcome someone with good knowledge of the
security API, and writers and translators. Finally, we need testers
for Mac OS X.

Collin: We need a technical documentation
writer, someone that can explain in good English
what we do, how the code is organized, or write a user's guide to
JDistro's desktop, so that
more people will come to this project.

HW: What advice do
you have for those who might want to modify the JDistro
source?

Desnoix: First, define precisely the feature you
want to add or fix. Then contact us to know what classes to
look at. The core of JDistro
is about 270 classes, but only a few of them should be impacted by a
feature.

Collin: You need to understand only a small
set of classes in order to know how JDistro
works. JDistro is only a boot
(JvmBoot class), a class loader (KorteClassLoader), a
security manager (MalnaSecurityManager), and some classes that
glue them together (KorteMain, WharfLauncher,
WharfLauncherApplet, etc.). Some parts of the code are quite
tricky, but [if you have] some good knowledge of Java internals, you
can easily understand it. You don't need to understand lots of
classes to understand JDistro.

HW:
If a developer wants to ensure their app is "JDistro
friendly," what should they keep in mind?

Collin:
In order to be compatible with JDistro, please use only
standard Java APIs, and don't do clever tricks that are too dependent
on the system.

Right now, don't use the
URLStreamHandlerFactory classes, because they use system-wide
settings we cannot overcome. The most important thing is: be sure to
close what you opened. Windows, Sockets, Files, and
Server threads must be closed when you quit the applications,
because JDistro will have a hard time doing it for you.

Desnoix:
There are a few things that may help:

Use Swing if possible.

Avoid relying on the component hierarchy. Code like this is prohibited:

Component c=this;
while(!(c instanceof MyFrame))
c=c.getParent();

Shutdown hooks are not yet supported. In the current release, they
will be executed when you quit JDistro and not the application.

Be sure your application can run with any look and feel. Don't use
specific UIs.

HW: Java continues to draw a following of programmers who love to develop for it, but it also still has its strong critics. What is it about the language that you love, which inspired you to create JDistro, and what do you speculate could be in the future for the language in the open source community?

Collin: Open source programmers have made a lot for Java, with most of the new development coming from them (generics, servers, XML). But programmers tend to talk quite frankly about their problems--they're using it every day; hence, they're strong critics, which may repel some potential new users.

I'm quite optimistic about the future of Java, and I think Sun is doing some clever things here. Eventually, we will have the Sun proprietary Java with the latest features, and at least one viable open source, completely rewritten Java. So we will have the best of both worlds, and they will remain compatible. Of course, JDistro will be working with the Classpath project. It may even modify some core classes to achieve 100 percent compatibility with existing Java applications.

Desnoix: Java has many flaws, but my main concern is about the APIs because it is what our software is built on. Most APIs use abstract classes (or even worse, concrete ones) instead of interfaces, preventing alternative implementations. And they can not be modified without breaking compatibility. That said, Java is very powerful and easy to program. This is definitively the best platform today and probably the reason why there is so much free software written in Java. GNU Classpath-based free JREs are progressing very quickly, and I hope/expect the FOSS community to choose and integrate Java in the next-generation, free systems.