Skip to main content

Threading in Plug-ins

3 replies [Last post]
cbare
Offline
Joined: 2004-02-02

Hi,

Going from Java 5 to Java 6, did something change with respect to threading in the way the plug-in dispatches calls from javascript to java?

I wrote an extension (a little toolbar) for the Firefox browser which embeds some java objects (see the Simile project at MIT for how to pull off that trick.) Something that worked using the JavaSE5 plug-in now fails in JavaSE6.

I'm seeing something weird that I don't understand: I make a call from the Javascript side to a java class. It appears to me that the call (which used to be synchronous -- the javascript thread would wait for the java method to return) is now asynchronous.

The method returns void, is unsynchronized, and has some important side-effects that hose me later if they're not complete. In general, the whole thing is on pretty thin ice threading-wise, so I'm not surprised I fell in a hole. But, I'd like to understand what kind of hole I've fallen into.

Did something about javascript-to-java calls change between 5 and 6? Was it always asynchronous and I just didn't know it?

Any clues appreciated, thanks!

- Christopher Bare

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
cbare
Offline
Joined: 2004-02-02

Well, apparently I've discovered a bug in the binding between Javascript and Java in the Firefox browser.

==== Javascript: ====

dump("test\n");

var goose = getJavaObject();

try {
dump("=== goose = " + typeof(goose) + "\n");
dump("=== goose = " + goose + "\n");
}
catch(e) {
dump(e);
}

var t = goose.getTrue();
dump("=== t = " + t + ":" + typeof (t) + "\n");
var f = goose.getFalse();
dump("=== f = " + f + ":" + typeof (f) + "\n");
var to = goose.getTrueObject();
dump("=== to = " + to + ":" + typeof (to) + "\n");

goose.barf();

// do above tests again...

==== Java: ====

public class Goose {

public boolean getTrue() {
return true;
}

public boolean getFalse() {
return false;
}

public Boolean getTrueObject() {
return Boolean.TRUE;
}

public void barf() {
throw new RuntimeException("Bleeeaaaahhhh!");
}

...

}

==== Output: ====

test
=== goose = object
=== goose = org.mydomain.MyObject@1ef8cf3
=== t = true:boolean
=== f = false:boolean
=== to = true:object

=== goose = object
toString() method failed
=== t = false:boolean
=== f = false:boolean
=== to = null:object

It seems that throwing an exception from Java back to a Javascript caller causes the throwing java object to go into some screwed up state. The result is that whatever value you return from the Java side gets lost. The javascript side gets some default value like false or null depending on the return type of the java method.

I don't really know who's bug this would be. Mozilla's or Sun's. There's definitely something going on in the glue between the javascript and java worlds.

-chris

cbare
Offline
Joined: 2004-02-02

I observed this behavior on Firefox 2.0.0.3 on WinXP with the java 1.6.0_01-b06 version of the java plug-in. I suspect this is a bug in the plug-in because this same code (throwing the same exception) used to work fine with the java 1.5.xx series plug-in.

cbare
Offline
Joined: 2004-02-02

Digging into it, my initial thought of threading problems seems to have been a hallucination brought on my the asynchrony of output buffers. But, I'm still getting something seriously weird.

-chris