Só mais uma dica.
Eu não sei o quão sensível é o seu hardware, mas o wait está sujeito a acordar sozinho de vez enquando (spurious wakeup), antes mesmo do seu timeout de 1 segundo ter passado. É raro, mas pode acontecer.
Se isso não for um problema, deixe o código como está. Mas se for sério, você pode alterar o código com o wait para que ele fique dentro de um while, que controla o tempo:
[code]
public synchronized void pause() throws InterruptedException
{
final long finalTime = System.currentTimeMillis() + 1000;
long remaining = 1000;
while (rodando && remaining > 0) {
wait(remaining);
remaining = finalTime - System.currentTimeMillis();
}
}[/code]
Aqui no meu caso acabo usando códigos como esse, pois faço aplicações que rodam milhares de testes numa central telefônica, onde cada um desses testes faz 2 ou 3 verificações de timeout. Uma falha em falso pode significar um usuário irritado, que teve de retestar quando não havia problema nenhum (fora que isso tem uma imagem muito negativa na confiabilidade do sistema).
Mais uma coisa. Você também pode testar se o interrupt() foi usado num lugar fora do wait (onde, nesse caso, nenhuma InterruptedException é lançada). Geralmente, quando vc usa uma variável de controle como a "rodando" isso não é necessário, pois a VM só vai dar um interrupt() quando a própria VM estiver sendo finalizada. Mas só para você saber que é possível e como se faz:
while (rodando && !Thread.isInterrupted()) {
...
}
Havia a idéia de se controlar o início/fim de threads com o interrupt(), que é um método da classe thread, quando o java começou. Mas essa prática parou de ser recomendada. Nunca pesquisei o motivo, mas eu gosto do fato de saber que um interrupt só vai acontecer numa thread por uma razão mais catastrófica, fora do meu próprio controle. Além disso, creio que é uma boa política separar o mecanismo de controle de uma thread (sua classe Runnable) do mecanismo de execução da thread em si (a classe Thread ou a classe ExecutorService).
