tags:

views:

431

answers:

4

I've been trying to learn about applets by studying the code for the "Welcome to HotJava" applet. I decompiled the *.class file using the Windows version of Jad, and I see the following lines of code

public void init() {
    // Skip some lines...
    addMouseListener(this);
}

public void destroy()
{
    removeMouseListener(this);
}

Is the destroy method really necessary here? Why does the applet need to remove itself as a mouse listener if it's just about to end?

+1  A: 

The destroy() is critical if you want to leave any "evidence" that your applet had ever run...

For example, you could send all your state information to a file or a server for subsequent use, or let the server know that you are disconnecting.

Imagine that you had a chat application...

Uri
I think I used a misleading title. I can see why you'd need this method (i.e. for cleanup), but I was more asking about this specific case.
allyourcode
+1  A: 

The destroy() method cleans up resources so they can be released. When the whole JVM will be shutting down, it's not as critical to release all resources before shutting down, but it's always a good idea to do The Right Thing even when it is not strictly necessary.

Depending on the threading model, if you leave yourself as a mouse listener, then you will still be notified if mouse events occur. If there are multiple Applets in the same JVM and only one Applet is ending, then you can leave threads in a funny state if you leave a listener to which no action will be taken. It's possible that you can lock up the other Applets by doing so.

EDIT:

By threads in a funny state, I mean (for example) if a listener whose Applet thread has stopped is queuing messages to a queue that no-one is reading from, then eventually the queue will fill up and the dispatch thread will block. (In more detail, let's assume the listener does nothing but queue the message and that there is a thread in the Applet -- now stopped -- that reads from this queue. Once the queue fills, it will block!)

With a mouse listener, specifically, you may well be safe, assuming when the Applet quits it is no longer visible and can no longer receive mouse events. With a different sort of listener, however, you could get into trouble. Always doing the right thing, even when it is not truly necessary, gets you in the habit so you don't forget to do the right thing when it's actually critical. :)

Eddie
This answer gets really close to what I was looking for. It mentions something I didn't know: there can be > 1 applet/JVM and not cleaning up can affect others. But I'm still wondering how threads can end up "in a funny state", b/c I don't see how there can be any more mouse events to listen to.
allyourcode
Just expanded my answer in response to the questions in your comment.
Eddie
+1  A: 

Its useful in releasing resources that exist outside the context of the applet. Lets say you have acquired a resource from a foreign server side application, like a license. Or perhaps you need to notify some server side resource that the application has shutdown for statistics or some other reason.

ng
See my comment to Uri.
allyourcode
A: 

Well, not in this particular case. However, it's good practise to remove mouse (and other) listeners in java - not doing so can result in unfortunate memory leaks.

And it's also good practise for your destroy() to clean up everything that init() does, even when it's unnecessary.

paulmurray