adding a stop() function clocks it to 995b uncompressed, which isn't bad, but if you're looking for 90 extra bytes towards the end of your game, this is one area to slash.this is the stop() function i used:

enable your applet console, and try this applet (which doesn't have stop()) to see if it works for you: http://woogley.net/misc/Applet4K/ (source). you should notice in the console it will stop printing "still running" after you navigate away from the page, with no ugly exceptions

Thread.currentThread().isAlive() will always return true, so that's a noop.

hmm, after testing in the console, it seems you're right o_O. mystery of life solved. at this rate, does it even need to implement Runnable? can it just run on the Applet's pre-existing currentThread() I wonder?

edit: nevermind, that was a bad idea. I successfully murdered firefox when trying that

start/stop method in an applet doesn't mean starting en stopping the applet as start and stop method can be called more than once.

init method means: nothing visible yet, applet panel not connected to screen, but you can initialise some stuff.start method means: start the applet (the first time) or resume from pause(for next call)stop method means: pause the appletdestroy method means: destroy the applet (the code to free and exit thread should be there)

soinit/destroy methods works together as constructor & destructor of appletstart/stop methods works together as resume/pause applet

usually/normally way is: stop method is called when browser is minimised and start when browser is restored or after applet init for first call

start/stop method in an applet doesn't mean starting en stopping the applet as start and stop method can be called more than once.

init method means: nothing visible yet, applet panel not connected to screen, but you can initialise some stuff.start method means: start the applet (the first time) or resume from pause(for next call)stop method means: pause the appletdestroy method means: destroy the applet (the code to free and exit thread should be there)

soinit/destroy methods works together as constructor & destructor of appletstart/stop methods works together as resume/pause applet

usually/normally way is: stop method is called when browser is minimised and start when browser is restored or after applet init for first call

stop is also called if you navigate away from the page running the applet. start is also called after navigation away, then returning to the page.

note: If the browser is not destroyed, the init method will not be called again. This where you can have trouble when testing an applet since the new jar will not be reloaded unless you close your browser or clear the classloader cache in the console.

it remove reference on thread, and exiting the run method kill thread , so no reference and thread not running (run method ended) anymore implied that it is freed.

Threads are freed after they terminate. You don't need to worry about having a circular reference. The JVM will automatically detect that both the dead thread and the Applet are ready for garbage collection.

I am just working on a bug I have with Firefox JRE 1.6.0.2... using severals Applets without closing browser, and believe me, unfortunatly Applets are "not freed" on FireFox.... releasing all reference in destroy method make the heap grow slower but doesn't resolve all problemes on FF, IE just works fine...

this is bunch of the code (maybe there is some stupids things in it as it is experimental, I am still working on it) I am working on to make applet released on FF:

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org