Java-to-JS calls fail when called from a new Java thread
Status: Beta
Brought to you by:
smichaud
The problem arises in the following scenario only:
1. method in frame[1] invokes Java method via applet reference in frame[0]
2. the Java method creates a new thread and returns after starting it
3. the new thread invokes a JavaScript method, implicitly in frame[0]
4. the JavaScript method tries to invoke a method that does not exist
5. at this point Java methods that attempt to invoke JavaScript methods in new Java threads will run JSObject.getWindow().call() successfully, but the JavaScript method will not be invoked.
The original discussion is located at
http://sourceforge.net/forum/forum.php?thread_id=1852856&forum_id=371125
Testcase and report
Logged In: YES
user_id=848669
Originator: NO
I can reproduce this, and I agree it's a bug ... but as best I can
tell it's a bug in Mozilla.org browsers (not in the Java Embedding
Plugin).
It also happens (with Firefox 2.0.0.9) on Windows (with J2SE 5.0) and
Linux (with Java 1.4.2).
It's conceivable that I could find a way to work around this bug in
the Java Embedding Plugin ... but that's not going to happen anytime
soon. This bug is just too obscure. And (as you've told me) it has
an easy workaround.
Interestingly, Safari (tested on OS X 10.4.10 and 10.5) has a more
severe variant of this bug: Both nonExistantMethod() nad
nonExistantMethodNewJavaThread() stop both log() and
logNewJavaThread() from working.
It's intriguing that the problems only happen across frame boundaries.
I can't explain that, but it's further evidence that these problems
are browser-specific -- neither the Java Embedding Plugin nor any JVM
(Apple's or Sun's) knows about frames.
Logged In: YES
user_id=1106678
Originator: YES
While my workaround worked for the original testcase, I continued to see communication failures when I integrated it back into our applet. I've created a far simpler testcase, which may highlight a different problem, but the end result is the same - JavaScript methods invoked by the applet don't execute.
Our applet invokes JavaScript methods as a result of RMI calls. These are inherently asynchronous and I associate a few calls in quick succession with Java to JavaScript communication failing. The testcase attempts to reproduce this scenario, but in fact just a single thread invoking JSObject.call every 50ms can often result in failure.
I've attached a thread dump from the JEP. At 14:09:05 all is well. At 14:10:16 the applet and selected tab are locked (other Firefox tabs appear unaffected).
As a workaround, I now use the applet to cache state and have JavaScript methods poll for state every second.
File Added: j2jstest.jar
Logged In: YES
user_id=1106678
Originator: YES
File Added: j2jstest.jar
Test case & JVM thread dump (original contained wrong thread dump)
Logged In: YES
user_id=848669
Originator: NO
I'm not going to be able to get back to this for a while. But first
let me ask the obvious question (in light of my comment of
2007-11-04): Have you done any testing in Safari, or in Mozilla.org
browsers on other platforms (Windows, Linux)?
If (as I now think) this bug (or these bugs) are browser bugs, it's
very unlikely that I'm going to fix it (or them).
Logged In: YES
user_id=1106678
Originator: YES
I appreciate your opinion - I just felt it prudent to log the issue here.
Seven runs of j2jstest in Safari reached 10,000 invocations without any problems, and 20 runs reached over 1000 invocations, at which point I stopped the test. This is in contrast to Firefox where the applet tab will lock after fewer than 1000 invocations, on average, on every second run.
I'll provide details of other browsers in Windows and Linux tomorrow.