JavaScript not being blocked/synched by Applet init()

[Richard J Maher]

Hi,

Not sure how the following behaviour would pan-out on the VMS-available browsers, but I'd like to know if someone could please tell me.

I've come up with a small reproducer (see below) that I hope will help
someone sched light on what's going on. (Also a related SDN Bug ID 6742814
may be of some help: -
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6742814 )

In a nutshell with IE6 the Javascript resumes as soon as the init() method
has called JSObject.getWindow(this) but *before* the init() method has
completed/returned, as can be evidenced from the getNum() results. (Nice
trick!) Try it on FireFox to see the difference.

Is this a new bug that was introduced when trying to fix a "freeze" with
JSObject.Call()? If not, how is one ever supposed to synchronize the
completion of Applet initialization? "Callbacks" a la mode de Adobe
FABridge?

I'll do some more testing with other browsers/versions but surely this can't
be right? Possibly fixed in a later version of IE, JRE, or LiveConnect?

To turn the Java console on on Windows: -
Tools->Control Panel->Java->Advanced->Show Java console

Java Console output IE6

[Alert box is "3"]

in getNum 1
in getNum 2
in getNum 3
in getNum 4
Before sleep call
After sleep call

Java Console output FF2

[Alert box is "36"]

Before sleep call
After sleep call
in getNum 34
in getNum 35
in getNum 36
in getNum 37

Cheers Richard Maher

Sleeper.java
============

import java.applet.Applet;
import netscape.javascript.JSObject;
import netscape.javascript.JSException;
import java.lang.InterruptedException;

public class Sleeper extends Applet {
private int myNum = 0;
private JSObject browser;

public void init() {
try {
browser = JSObject.getWindow(this); }
catch (netscape.javascript.JSException e) {
e.printStackTrace(); }
catch (Exception e) {
e.printStackTrace(); }

System.out.println("Before sleep call");
try {
Thread.sleep(5000);
}
catch (InterruptedException e){
e.printStackTrace();
}
System.out.println("After sleep call");
myNum = 33;
}

public int getNum(){
int i = myNum++;
System.out.println("in getNum " + myNum);
return i;
}

}

Sleeper.html
============



"http://www.w3.org/TR/html4/loose.dtd">



<meta name="author" content="Richard Maher" />
<meta name="description" content="JS Function and Applet Test" />






<script type="text/javascript">

function load() {
var lclNum;
var chan;
try {
chan = document.getElementById("Sleeper");
lclNum = chan.getNum();
lclNum = chan.getNum();
lclNum = chan.getNum();
}
catch (err) {
alert("In catch " + err.description);
}
if (chan == null) alert("chan is null");
alert(chan.getNum());
}

</script>

Test it

---

type="text"
style="text-align: Left;"
name="next"
size=10
/>

<script type="text/javascript">

var myDef;
if (navigator.appName == "Microsoft Internet Explorer")
myDef =
''
else
myDef =
''

document.write(myDef);
</script>





"Richard Maher" wrote in message
news:gsmp8k$hfo$1@news-01.bur.connect.com.au...
> Hi,
>
> I'm probably seeing-things again but here goes: -
>
> IE6 with JRE 1.6.0_12 looks to continue the Javascript processing while my
> Applet.init() has yet to return. FireFox is fine and when I went for a
small
> reproducer IE also performed as expected. (Both with Applet appended in a
>

or document.writeN() as an

[Richard J Maher]

Upon re-reading that bug report I quoted, I've come to the conclusion that (for whatever compelling reasons) it was a deliberate break of upward-compatibility and the laws of browser-physics as we knew them pre-Java6. (Java 1.4 and I'm guessing 5 behave "as expected" with IE6)

A couple of relevant-sounding quotes from that bug report from Sept last
year: -
{
The rules for initiating JavaScript-to-Java and Java-to-JavaScript
calls (which will be formalized in the forthcoming new LiveConnect
specification) are:

- JavaScript-to-Java calls against a given applet block until that
applet has completed init(), or

- that applet initiates a Java-to-JavaScript call in init().
}

The definition of "initiates a Java-to-JavaScript" in that last line appears
to have been further broadened and amplified to include: -
{
- If a request comes to the browser from an applet to fetch the
JavaScript window object corresponding to the applet, drain the
queued up messages corresponding to JavaScript-to-Java calls,
which would otherwise occur when init() was completed.
}

So it appears that through the wonders of Java6 we now have your init()
method and your JavaScript executing in parallel (presumably in seperate
threads), but *only* if you're doing something with JSObject. And for the
squeamish among us that like our initialization to finish before the
mainline methods start crunching numbers, there's now a need for
intervention.

I do glance through the JRE release notes when they come out but can't
recall seeing this one; anyone else?

Anyway, thanks to a guy in cljp, the answer is to "synchronized" all applet methods that need it. (Or at least init() and the one you want to call from JavaSCript to block on.)

Cheers Richard Maher

PS. Happy Mother's Day to all the Mums in this part of the world!