Skip to main content

Java plug-in wish list: JVM scope

Posted by carcassi on March 5, 2009 at 12:11 PM PST

The second generation plug-in really made me reconsider applet as a viable deployment method (though people who are not aware of the improvements think I am crazy). For the project I am working on ( we decided that the user interface would be a series of applets that communicate through a Java API to a REST Web Service. The second generation plug-in was really essential to be able to do that. The ability to have each application run in a separate JVM, the ability to give each JVM more than 64MB and the ability to use javascript on top were all necessary.

One thing in particular, though, I think is needed: JVM applet scope. That is: the ability to run a set of applets in the same JVM, controlling which ones go together. The two real cases that I would need are "page" (all applets in the page scope on the same page instance share the same JVM) and "application" (all applets in different pages that declare to be in the same application share the same JVM).

The first is really to have different applets that can interact with each other, and it would actually go together with the ability to drag applets out. You can imagine two applets, one that is essentially a display of some data, and the other with the parameters for the display. You set your display the way you want, and when you are done you drag the display out and close the page.

The second would be used to share data cache. I have multiple pages that work on the same big dataset, and I would like different pages to simply use the same cache.

JVM scope would also automatically decrease the JVM startup time to 0 in certain, with no real effort. And it really allows me to create complex standalone widgets that can be assembled in pages through HTML, javascript or whatever javascript framework is in today.

Any chances?


You mean something like applet.getAppletContext().getApplets() and applet.getAppletContext().getApplet(String name)? About sharing objects between different JVM what about JavaSpace?

@heaththegreat: in javascript, you can only pass java objects back to the same JVM that created them. So, if you have two applets isolated, they can't communicate using Javascript. If they all share the single "browser" JVM, you can, but that's intrinsically bad for other reasons @coxcu In the old plugin you had all applets living in a single browser scoped JVM. In the new plugin, you can choose between that, or a single, independent JVM created for you applet. A new java process. I want to be able to have a set of applets live in a new, separate, java process sharing the same codebase, same classloader. If I have a singleton at the API level, all my applets see the same singleton... Is that more clear?

What do you mean by JVM? An aggregate, an isolate, or something else? Yes, I know that JSR-121 is unlikely to make it into any consumer oriented JRE any time soon, but I can dream.

@heaththegreat: Yes I can use livescript, but I suppose that Gabriele want this enhancement to reduce the large per-process footprint of the JVM. The Java platform already trails all other competing RIA technologies when it comes to resource usage; making that another 2-3X worse because some page needs 2 or 3 separate applets would totally kill Java.

You could accomplish what you want today with livescript. With the livescript apis, your applets can communicate with javascript and vice versa.

Hi opinali: From my perspective, application scope could require not only that all applets are signed by the same key, but come from the same codebase. The idea is that they are pieces of the same application, or better, different "windows" of the same application. So, maybe you could call it "codebase scope"? I'd think that in that case the security implications should be similar to the single applet, but then again, I am not a security expert... Gabriele

Applet scope is a fine idea and probably not hard to implement (just make sure, in the Applet API, that two istances of Applet have the necessary resource separation - if that's not already so). But Application scope potentially opens a big can of worms - cross-site security issues. Perhaps that would be still reasonable, for example if we restrict all applets within the same App scope to be signed by the same key.