15389 - NULLPointerExcepion when calling JSObject in applet constructor.

Status: VERIFIED WONTFIX

(Core Graveyard :: Java: OJI, defect, P3)

Description

[Leila Garin]

Using daily Mozilla build on WinNT and jdk1.3. This is a backward
compatibility LiveConnect bug since the example would work in Nav 4.x.

The applet code 'JSObject.getWindow(this)' results in a NULL reference
acception when called from the applet's constructor, but works when
called from the applet's init() method. Both cases work in Nav 4.x.

Comment 1

[Jeff Dyer]

A NullPointerException is thrown on line 144 in
java.applet.Applet.getAppletContext. Apparently the reference to Applet.stub is
null at this point of execution.

AppletPanel.runLoader creates the applet via AppletPanel.runLoader. The applet
constructor calls Applet.getAppletContext, which uses the Applet.stub.
Applet.stub is set in AppletPlanel.runLoader after AppletPanel.createApplet is
called. The problem is caused by an implementation of
netscape.javascript.JSObject that is a Sun substitute for the Netscape version.
Apparently the substitute enables the applet to access the JavaScript DOM. At
least that is what the header comment says.

The call stack at the time of the exception looks like this:

java.applet.Applet.getAppletContext(Applet.java:144)
netscape.javascript.JSObject.getWindow(JSObject.java:126)
RexTestApplet.<init>(RexTestApplet.java:16)
java.lang.Class.newInstance0(NativeMethod)
java.lang.Class.newInstance(Class.java:241)
sun.applet.AppletPanel.createApplet(AppletPanel.java:566)
sun.plugin.AppletViewer.createApplet(AppletViewer:977)

Two ways forward:
1. Say that LiveConnect can not be used until after the applet constructor
completes execution. This breaks compatibility with Nav 4.x.
2. Modify Sun's implementation of JSObject.getWindow to handles the case where
the applet context has not yet been fully initialized.

Comment 2

[drapeau]

I'm in favor of modifying Sun's implementation of JSObject.getWindow(), if you
believe this is possible.  I don't know where the source for that implementation
resides, but if the source resides in the Mozilla source tree, I don't see any
big problem in us making changes.  If the source resides in the JDK or in the
Java Plug-In code, then I believe we can make changes and submit them via Sun
channels.

Tell me more, please.  And, do you have a recommendation yourself about which of
the two options to use?  (My vote is for option #2, but I'm interested in your
thinking)

Comment 3

[Jeff Dyer]

The code for the replacement JSObject is in the plugin. I agree that the better
solution is option 2, which maintains backward compatibility. The substitute
implementation is written by Stanley Ho. I suppose the first step to finding a
fix is to get him in on the discussion. Do you know where to find him?

Comment 4

[drapeau]

I'm adding both Stanley Ho and Tom Ball to the CC list for this bug, so that
they can look at our comments.  Maybe Tom (or Stanley) can tell us how we can go
about making the change to the substitute implementation of
JSObject.getWindow().

Comment 5

[drapeau]

I'm adding both Stanley Ho to the CC list for this bug, so that
they can look at our comments.  Maybe Stanley can tell us how we can go
about making the change to the substitute implementation of
JSObject.getWindow().  I will also forward this to Tom Ball so he can take a
look.

Comment 6

[stanley.ho]

By default, applet is not meant to be in a known state until Applet.init() is
called. Thus, calling JSObject.getWindow(this) in the constructor should NOT
work because the environment is not meant to be fully initialized for the applet
yet. Adding support for this will be tricky because of the way applet is
constructed in Sun's JVM and other JVM. I don't think we can make every OJI
plug-in out there to behave consistent on this issue easily. I would prefer
option #2 - wait until Applet.init() is called.

Comment 7

[Jeff Dyer]

I agree with Stanley. Although it would be nice to maintain backward
compatibility, that this code works in Nav 4.x is surprising. In both C++ and
Java, there is no guarantee that an object is usable before it is fully
initialized (that is, its constructor code has completed execution). Constructor
code that passes 'this' to an arbitrary function is asking for trouble.

Comment 8

[drapeau]

Okay, it looks like the two experts here agree that option *one* (Stanley, you
meant to say option "one" ---"Say that LiveConnect can not be used until after
the applet constructor completes execution. This breaks compatibility with Nav
4.x," not option "two") is the correct way to go.  This error condition was
created in an undefined state: JSObject method calls cannot be guaranteed to
work from within an applet's constructor.  Navigator 4.X's behavior is
fortunate, but not well-defined.  Furthermore, as Stanley suggests, we cannot
guarantee identical, fortunate working behavior with all OJI-compliant JVM's
written by multiple vendors given this undefined state.

I am therefore closing out this bug.  Backward compatibility with Nav 4.X is
actually dangerous in this case, since it would be propagating errors forward.

This is not a bug.