Poor man's Multi-VM
By user12610627 on Nov 29, 2006
I was prompted to do this by Gilad Bracha (who unfortunately left Sun recently). Gilad told me that he didn't believe in Java GUI's for two reasons:
- Start-up time
He mentioned a test they did comparing the SmallTalk Squeak IDE, which started up in about 3 seconds and used about 25M of memory, compared to Netbeans which in this test took a minute to start up and used over 100M. But of course you may not consider this a fair test. So next they simply took a screenshot of the Squeak IDE and then wrote a tiny Java program just to display the screenshot. This second program took 3 seconds to start up and also used about 25M of memory, but in the first case we had a fully-functioning SmallTalk IDE and in the other just a bitmap.
I personally found his arguments undeniable.
I did my own tests where I ran 10 instances of SwingSet2 in separate JVMs versus in the same JVM but with separate application contexts. In the former case total memory use was 540M, in the latter 74M.
As I mentioned this approach isn't specific to F3.
I put a zip file containing the basic code to do this for regular Swing applications here (45kb).
Note: this is just example code to illustrate how you could do this.
The zip file contains the source and compiled code and some windows batch files to build and run it (Java 1.6 required to build, Java 1.5 to run).
There's only one class called JApplication. You call its main method with a class path and class name similar to how you run the java command, e.g.
java com.sun.JApplication -classpath SwingSet2.jar SwingSet2
When you run it the first time it creates a server socket on the local host and listens for subsequent connections. At the same time it creates a new thread group, class loader, and application context and runs the application you specified (i.e in this case SwingSet2). When you run it subsequent times it simply connects to the port and writes the command line argument over the socket. The original then creates a new thread group, class loader, and application context as above and runs it in the address space of the original vm. In addition, writes to System.out and System.err from that thread group are redirected back to the socket so you see the console output of your application as expected. It would also be possible to write a C program or shell script to launch your application (rather than using another JVM).
Finally, if you're using Java 1.6 it adds an icon to the system tray which has a menu to shut down the whole thing and also can display a window listing the running applications and which allows you to kill them manually.
Note that this example code doesn't handle security issues at all.