The aim of this project is to produce a piece of software that is at the same time:

Shared virtual machine
It allows to launch different java programs inside the same VM. The VM will always be alive, so no more startup overhead and less memory used.
It uses our JDSVM(Java Desktop Shared Virtual Machine), which in turn is based on Javagroup's great Echidna Project

Xml Rpc local server
This way it is possible for programs, even written in languages different from java, to access "services" exposed by the engine.

Plugin host
It has been built with a pluggable architecture in mind, so that it is possible to develop new "services" for the engine.

Linux/Windows service (next release)
It is run as a service, so that its "services" will always be available for other programs.


Please take a look at the Overview and Tutorial sections for details.

Download

Release 1.0 of "Java Desktop Engine" is now available. Click here (800KB) to download.
Source code for this version will be available soon.

Overview

For those of us who make heavy use of java tools it's always been quite frustrating to have to open lots of resource eager VMs just to launch very useful but simple programs. Moreover, VM starting for simple utilities is a real waste of time. We've all appreciated the difference when launching a compilation from inside an IDE. In this case javac is launched as a process inside an already active VM, and the difference is evident.

JDE in the beginning was born to try to address these problems. Having an always active VM where it is possible to launch processes in, means faster process start and less resources used. A lot of time is saved by from not loading again and again the VM.
There's nothing new in this. Some very good related projects are alive and kicking on the net, some of them focusing on a complete Java desktop enviroment, some on just a shared VM. JDE positions itself a bit differently, as it can be seen as a java engine exposing pluggable services (shared VM being just one of these).
There are several approaches to implementing a shared VM, all of them with pros and cons. We've chosen to use the great code from the Echidna Project for now. A more technical document on this is planned......

There are some bad news. Let's quickly review them:
1) Shared System statics. System.in, System.out,System.err are shared inside the VM. Yes, we could define a different set of System statics for each process running inside our VM, but this will imply modifying the code of the application to make it "compatible" with JDE.
2) GUI event queue.
There's just one GUI event queue per VM, so for example, an active modal dialog in whatever process will be modal for the entire VM GUI.
3) Security issues.
Obviously, this approach breaks the VM sandbox. There are some different solutions to address this problem, all of them being partial though. Anyway, depending on the use we'd like to do of JDE, this could or couldn't be a problem.
4) A process crash could crash the entire VM.....:(
Well behaved programs shouldn't crash, anyway.......

The entrypoint of JDE is an XML-RPC server accepting calls for services. Everything needed from JDE can be obtained by making a call to it.
The main service exposed by JDE is obviously the java process launching one. By making a call, it is possible to launch a java process insisde the VM. Having an XML-RPC server allows us to use any language with xmlrpc capabilities to launch java programs. The package includes a simple python script, that can be easily used as launcher (see our simple tutorial for details).

Included is also a "Manager", a simple swing application with active process listing and process launching capabilities.
Hopefully, this one will evolve as far as there will be more services in JDE to be the reference manager for the engine.

Included plugins:
1) Java process Launcher. The one this project was started for. You can launch java processes inside the living VM.
2) Scripting engine. Via a simple xmlrpc call you can launch a script on the engine and get back results. The nice thing, as usual, is that being xmlrpc based, you can use it as a service called by anything written in any language. Currently supported scripting language is BeanShell. More will be available soon via BSF.
3) Fast editor Based on jEdit Syntax Package 2.2.1, a simple, fast and useful editor with only some of the nice features jEdit has got us used to.
More to come.................

I'm currenlty making daily use of JDE and, though in beta stage, it seems quite stable.
This is a shot of some programs together with the JDE manager running inside a single virtual machine.
(click the snapshot to see the enlarged image)



Just to give you a rough idea, the entire VM (shared VM + manager + all the programs) on a Mandrake Linux, kernel 2.6.0-1, J2sdk1.4.2 with no special VM options takes 46MB. On the same configuration, the same programs launched on single VMs take more than 3 times the memory.

What's missing Basically, tons of things. JDE is currently not focused on security. This needs to be addressed ASAP. I'm not sure future releases will be based on Echidna, as other frameworks are being tested. I'm also trying to find a solution for the GUI (single) event queue problem, and honestly I'm not sure it can be solved on current VMs. Lots of plugins/scripts needs to be implemented; some are being developed just now and some are to come as the project goes on. Better arguments parsing by the launching scripts and also different programming languages (currently included scripts are in Python) are being prepared. JDE has only been tested on Linux, but it doesn't make use of anything but standard java features, so I'm quite confident it runs on other platforms too.

(not yet a) Tutorial
Well, I'll write down a real tutorial if enough interest arises on the project. For now, just consider it as a kind of "what you can do with this release" document. Basically, core functionalities are already active. You can run processes or scripts inside one VM , you have a manager application to launch/kill them, some python scripts to make xml-rpc calls to the engine and a few other things. The engine works, and depending on the kind of application you launch inside of it, it's quite stable.
So, let's switch it on....

A J2DK >= 1.4.0 should be all you need....

Next release there will be an installer, I hope... Anyway, even now it's not that difficult. Just "untar" the downloaded file. It will create a directory structure. Here is a brief explaination of what you'll find there:

Directories

• - lib containing jars of libraries/plugins loaded at start time by the engine
  
• - scripts containing scripts(currently only BeanShell scripts) automatically seen by the engine(more on this later...)
  
• - conf configuration and policy files
  

Files

• - startup.sh just run it (on Linux) to launch the engine(waiting for having the engine as a unix service....)
  
• - jva/jde python scripts to use the engine(more on this later...)
  
  

Run the "startup.sh" script. You need to have the "java" executable in your classpath. Not so elegant, I know it.... Two startup parameters have been implemented up to now:
1) GUIManager ,will also launch the Jde manager graphical application.
2) -LnF <look'n feel> ,being <look'n feel> the main class of a look'n feel implementation and provided that the corresponding jar file is in "lib", will launch the engine with the specified look'n feel.
I.E. : imagine you want to use the Liquid LnF (it's one of my favourite), you'll need to put the LiquidLnF.jar file in $JDE_HOME/lib and launch JDE like this: startup.sh -LnF com.birosoft.liquid.LiquidLookAndFeel
Note: If I launch a process that sets a different lnf, the following launched processes will inherit the new lnf. I guess the lnf setting is global to the VM.....

Ok, you've launched the engine, and now?
You can launch processes inside the engine by using the manager application(next chapter), or by making simple xml-rpc call to the engine. In $JDE_HOME, you'll see a python script, "jva", which does just this. You need to call it this way:
jva <classpath> <main class> <program parameters>
I.E. : if you need to call the following class: org.my.class which resides in the jar file: /home/my/myclass.jar, then just call:
jva /home/my/myclass.jar org.my.class, similar to "java" but without flags. Be careful to always use absolute classpaths. This script is a preliminary version, will be much more complete and powerful soon. Another useful script if "jde"(same location of jva). This will evolve into a Jde manager script, for now it handles scripts. You can launch it with two different command arguments:

• getScriptList will give you a list of the installed script in $JDE_HOME/script
• launchScript <scriptname> will launch "scriptname".
  I.E. : launching "jde getScriptList", you'll get a list of installed scripts. One of them is "Editor.bsh". To launch it just type "jde launchScript Editor.sh". That's it.

"jde" and jva" scripts are just examples of how simple it is to interface with the engine using languages different from Java.
Virtually any language with xml-rpc support is able to interact with JDE painlessly.

You can launch it in two ways:

• Launching JDE with "--GUIManager" argument
• "jda ./ org.beanizer.jdsvm.manager.ManagerSwing" (note the classpath parameter
  is not important,as used classes have already been loaded).

The "1" section of the screen allows to launch processes, just like "jda" script. Section "2" keeps a list of active processes and allows to kill them. Just select one process and click "Kill". The list gets updated automatically when processes are launched/killed. "Refresh" just does what it says.
The menu voice "History", keeps a list of launched processes. For processes launched more than once, only one reference is kept. It's very useful for repeatedly launched programs/utilities. Future releases of the manager will include plugins/scripts installation/disinstallation, engine statistics, and lots of completely useless but fancy features ;)

• A lot of debugging
• Evaluation of a different multi-process model
• An installer,auto updater and online plugin repository(a la jEdit)
• New and (hopefully) useful plugins (ideas/suggestions are much appreciated)