Por que o compilador não detecta isso?

JavaTeenager Membro desde: 09/02/2008 01:12:58 Mensagens: 189 Offline

Mais uma da série "por que o compilador não detecta isso?"

O código compila normal, mas o problema é que o lock da variável t não foi adquirido então vai gerar a exceção IllegalMonitorStateException. Mas como o compilador não consegue ver isso? Pra mim seria fácil, bastava o compilador ver se a instrução "t.wait()" está dentro de um bloco "synchronized(t)".

GUJ Master Membro desde: 01/07/2008 20:59:17 Mensagens: 1055 Offline

TiagoTC wrote: Pra mim seria fácil, bastava o compilador ver se a instrução "t.wait()" está dentro de um bloco "synchronized(t)".

É muito fácil para o compilador ver se a variável de referência usada no synchronized é a mesma usada para chamar o wait.

Mas o compilador não tem como saber se o objeto referenciado por t no momento em que synchronized (t) foi executado é o mesmo que t referencia quando wait é chamado em t.

Exemplo:

E se ao invés de fazer o=t eu fizesse o=u? Como é que o compilador vai saber que o objeto não é mais o mesmo?

GUJ Master Membro desde: 29/05/2008 14:09:28 Mensagens: 1616 Offline

Bem, isso seria um desastre, pois você somente poderia colocar uma chamada a wait no mesmo escopo de um bloco synchronyzed. Além do mais, essa não é a única possibilidade de uso do método wait. O fato, é que isso não é responsabilidade do compilador. O compilador trabalha somente até o nível sintático da linguagem, e não no nível semântico. Para o compilador, t.wait() é uma chamada a um método como qualquer outra.

JavaTeenager Membro desde: 09/02/2008 01:12:58 Mensagens: 189 Offline

rmendes08 wrote:Bem, isso seria um desastre, pois você somente poderia colocar uma chamada a wait no mesmo escopo de um bloco synchronyzed. Além do mais, essa não é a única possibilidade de uso do método wait. O fato, é que isso não é responsabilidade do compilador. O compilador trabalha somente até o nível sintático da linguagem, e não no nível semântico. Para o compilador, t.wait() é uma chamada a um método como qualquer outra.

rmendes08, mas quando o compilador, por exemplo, verifica se um método A está ou não capturando uma checked exception (ou jogando-a para frente com o throws) não é nível semântico? Pq a sintaxe está perfeita... mas ainda sim o compilador detecta que está faltando capturar ou lançar a exceção.

Essas coisas que geram dúvidas em mim sobre o que o compilador pode ou não detectar.

Mas, no caso da pergunta desse tópico, já entendi a resposta pela explicação do rod.attack.

http://imasters.uol.com.br/artigo/8787/java/mais_um_pouco_sobre_threads_em_java/

dar uma olhada, para ver se ajuda o por que da sua situacao.

Notícias, artigos e o maior fórum brasileiro sobre Java