In Navigator's 4.5 Java runtime environment the method Applet.getAudioClip(java.net.URL) allocates space for audio data and returns without fetching the data from the URL. Method AudioClip.play() then first fetches the data and then starts the play. In other runtime environments method getAudioClip both allocates the space and fetches the data. In addition to it Netscape environment cannot load audio data from jar (Java archive) files. So it is currently very difficult in Navigator to properly synchronize the play with any event.
In Navigator's 4.5 Java runtime environment the method Thread.interrupt() that normaly causes a thread to terminate any waiting or sleeping does not work. In Java applets the processing threads are usualy terminated in Applet.stop() method. This method sets some flag causing the thread termination and calls corresponding Thread.interrupt() method. Then it periodicaly checks if the thread terminated and when it is the case, it returns. In Navigator the processing threads can terminate on this way only when their prescribed sleep is finished. When you navigate away from the page with an applet, its stop method is called. When you navigate back the applets start method is called but only after the stop method returned. This may take long time when the stop method terminates threads with lots of long sleep. Threads can be also terminated by Thread.stop() method that works immediatelly no matter if the thread sleeps or not. But Sun Microsystems ask people not to use this method. It writes:
This method is inherently unsafe. Stopping a thread with Thread.stop causes it to unlock all of the monitors that it has locked (as a natural consequence of the unchecked ThreadDeath exception propagating up the stack). If any of the objects previously protected by these monitors were in an inconsistent state, the damaged objects become visible to other threads, potentially resulting in arbitrary behavior. Many uses of stop should be replaced by code that simply modifies some variable to indicate that the target thread should stop running. The target thread should check this variable regularly, and return from its run method in an orderly fashion if the variable indicates that it is to stop running. If the target thread waits for long periods (on a condition variable, for example), the interrupt method should be used to interrupt the wait.
These troubles will be or already are removed in next versions of Netscape Navigator. If you wish to determin if Java runtime environment supplied by your browser supports thread interrupt, access this page