Question

I have a page with multiple applets (yes, it's old). One of these applets overrides the stop method, as follows:

@Override public void stop() {

 System.out.println("Stop called!");

}

But, when I do this, nothing is displayed in the console (yes, the java console) when I switch tabs, or do anything else that should call stop(). The same problem is happening with overriding destroy(). However, the start() and init() functions work as expected.

My applets are extending another class, which in turn extends JApplet. I did this to give all of my applets access to specific functions (defined in this in-between class). These applets also create other threads for repetitive tasks, but I don't think that should affect the life cycle methods. I'm not sure where to look at this point, is it possible that the focus functions or something else like that is preventing the lifecycle methods from executing, or does having multiple applets on one page cause problems with these methods? Thanks beforehand.

EDIT: I have posted a SSCCE on my server to show this behaviour Click here to run and Here to dowload sources, it's a simple applet that starts a thread, which calls a method in the parent applet that opens a JDialog. You'll notice that you can close the browser tab while the dialog is open (as long as there are other tabs open) and neither the stop or destroy print statements will occur in IE10. On top of that, the JVM keeps running, and the Java console does not close. However, if you acknowledge the pop-up before closing the browser window, everything functions as expected.

So, the question then, is if someone closes the browser window while a popup is open, how do I kill the extra thread, and the pop-up itself?

Was it helpful?

Solution

The JDialog mentioned is created using JOptionPane. Quoting from the javadoc

All dialogs are modal

Modal dialogs effectively block the applet preventing the stop and destroymethods in the applet from being called. You could simply make the dialog non-modal

popup.setModal(false);

OTHER TIPS

After downloading and expanding the Zip, and turning the 2 sources into an SSCCE (an SSCCE is one source file by definition), I noted the same behavior in IE9.

It seems to me this is yet another example of a browser/JVM interaction bug. In FF the user is unable to close the page or change tabs when the dialog is open. That leads to a behavior that is as we'd expect, since the dialog must be closed prior to the applet tab being closed (or tab change or the browser being closed).

In IE9 (and 10, according to your report), the page can be accessed despite the visibility of the dialog, leading to all the problems.

Unfortunately the only work-around I could think of, didn't (work). Sometimes the necessary event can be detected by a ComponentListener, but in this case, it does not fire on closing the tab or changing tab.

So, I suggest you search the bug database for anything similar. If you find nothing, raise a new report and see what Oracle has to say on the matter. If it is a bug and they think it is the fault of IE, they can take it up with MS.

I switch tabs, or do anything else that should call stop(). The same problem is happening with overriding destroy(). However, the start() and init() functions work as expected.

Life Cycle of an Applet Doc page says:

When the user leaves the page, for example, to go to another page, the browser stops and destroys the applet. The state of the applet is not preserved. When the user returns to the page, the browser intializes and starts a new instance of the applet.

So yes I am having the correct result when i try to change the page on which applet is running, the stop() and destroy() method gets called and stopping and destroying gets printed. If by switching the tab you are meaning selecting one tab among the opened tabs, this is not to cause stop() and destroy() get called. However if you run JApplet directly from an applet viewer using Netbeans/Eclipes you will see that window state change(e.g., iconified, normalized) will cause stop() get called. destroy() will be called if you close the JApplet viewer.

You'll notice that you can close the browser tab while the dialog is open (as long as there are other tabs open) and neither the stop or destroy print statements will occur in IE10.

well i have tested with IE9 as i don't have IE10 now, i noticed in IE9 unlike in Firefox that the JDialouge lets switching tab among the opened tabs but it let neither the browser nor the page containing the applet get closed until acknowledging it. So it has something to do with IE10. you can try to use javascript to call an applet function to force it to be exited on window close event. I am not sure about this though as i mentioned, i don't have IE10.

On top of that, the JVM keeps running, and the Java console does not close. However, if you acknowledge the pop-up before closing the browser window, everything functions as expected.

I am a little bit confused here. Actually both Firefox and in IE9, i have experienced that after closing the page containing JApplet, jp2launcher.exe takes at most 2 mins time to exit itself and java.exe. In the mean time if you reopen the page containing the applet, it will start instantly without asking for any permission as it would ask first time when it got loaded.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top