Juggle Your Java with JDistroby Howard Wen
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
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.
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
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
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
for a full JNLP client.
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
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.
Our classloader modifies the bytecode of the classes it loads
and replaces, for example, all calls to
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
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
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.
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
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 (
security manager (
MalnaSecurityManager), and some classes that
glue them together (
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.
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.
- Use explicit paths. Don't write:
new File(System.getProperty("user.dir")+ System.getProperty("file.separator")+ "myfile.txt");
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.
Return to ONJava.com