Você já removeu ou desabilitou as
saídas de testes (debugging)??
As saídas de teste (geralmente criadas com System.out.println()), embora sejam úteis para você, são geralmente muito confusas para os usuários. Se você precisa dar um retorno textual para o usuário, tente fazê-lo dentro da área de display do applet ou na área de status na base da janela (veja o método showStatus() da classe Applet).
O seu applet pára de executar quando
está fora
da tela?
Muitos applets não devem usar recursos da CPU quando o browser está iconificado, ou está mostrando uma página que não contém o applet. Se o código do seu applet não dispara (launch) nenhum thread explicitamente, então está tudo OK.
Se o código do seu applet lança algum thread, então a menos que você tenha um ótimo motivo para não fazê-lo, você deve implementar o método stop(), para que ele pare e então destrua (setando os seus valores para null) os threads que você disparou.
Por exemplo:
public synchronized void stop() { if (refresh != null) { refresh.stop(); refresh = null; } }
Se o applet faz algo que pode se
tornar tedioso - tocar sons
ou movimentar animações, por exemplo - ele provê algum meio de se parar
com isso?
Seja legal com seus usuários. Dê a eles algum meio para parar a música dos applets, por exemplo, sem sair da página. Em um applet que não responde a clicks de mouse, você pode fazer isto implementando o método mouseDown(), que, ou suspende, ou retorna o thread, com um click de mouse.
Por exemplo:
boolean threadSuspended = false; //variável de instância public boolean mouseDown(Event e, int x, int y) { if (threadSuspended) { myThread.resume(); } else { myThread.suspend(); } threadSuspended = !threadSuspended; return true; }