Os Threads estáticos estão morrendo nos plug-ins novos! :(

Você tem certeza disso? (o que acontece agora é o que eu esperava que acontecesse de qualquer modo - o estranho era a JVM ficar ativa)

Posso perguntar? Certeza absoluta? Está certo disso?

QQ coisa estática sobrevive apenas para a sessão da JVM, quando você sai da página a JVM é finalizada também e pronto. Não acredite que haja uma maneir automática de ter esse comportamento …

Você sempre pode serializar o objeto, enviá-lo para o servidor (pq nao da pra salvar no disco do usuario sem permissao dele) e depois recuperar … trabalheira provavelmente desnecessária.

O Thread estático ficava “vivo” sim!!! Pelo menos nas versões da JVM inferiores à 1.4… Mas calma lá! Não falo em fechar o browser! Falo apenas em navegar por outras páginas do site que não contém o applet que invoca/cria o Thread! Eu fazia referência à instancia por outros applets normalmente…

Esse comportamento “surpresa” de encerrar os Threads estáticos me deixou p… da vida, pois projetei um sistema inteiro na JVM 1.3 e rodava tudo tranqüilo! Mas depois que instalei o plugin 1.4 passou a “matar” o Thread estático!

Que esquisito, pensava que só era problema de classloader (ou seja, quando você cria uma nova instância do applet, um novo classloader é criado, ou seja, aquelas classes antigas não são mais acessíveis, mesmo que estejam presentes.) Dá para saber se a thread realmente morreu, ou se ela está inacessível (devido a problemas de classloading?)

Isso é uma sacada muito legal da JVM da Microsoft, que faz com que um thread ou mesmo uma classe estática não morra entre uma página e outra. Na verdade, SE O CODEBASE FOR O MESMO, a JVM da Microsoft reutiliza a mesma virtual machine ao longo da sessão, e isso te facilita a vida em diversas coisas !!!

Já o PLUGIN da Sun não faz isso, porque eu não sei…

Graças a Deus que a Microsoft e a Sun se entenderam e a JVM da Microsoft vai continuar disponível para o IE até o final de 2006, se eu não me engano.

Agora preste atenção nisso: Se o codebase do applet for diferente, outra VM independente é usada. A regra é: uma VM para cada codebase !!!

Depois me avise se vc conseguiu fazer isso funcionar no PLUGIN da Sun. Eu nunca consegui e acho que não tem como…

Olá

Sérgio, para que serve a JVM da M$? Acaso você não quer nada mais do que um joguinho da velha?

O plugin funciona direitinho com todas as features prometidas. Participei de um grande projeto que o usou (j2sdk1.3.1) e não tivemos nenhum estes problemas.

Acho que fazer o download de no mínimo 8 Mb (plugin jre 1.3.1) para uma pequena applet no meio de uma página html fica meio estranho. Nosso projeto era todo uma applet (mais de 1200 classes), não haviam páginas html.

[]s
Luca

O PLUGIN da Sun é maravilhoso e funciona muito bem !!! Te dá suporte a SWING e outras coisas a mais que o da M$ ignora.

Mas não funciona para o meu caso em particular, e nem para o do amigo aí em cima.

Precisamos que um applet que apareceu na primeira página deixe um thread ou uma mensagem numa variável estática para um outro applet que vai aparecer depois em outra página.

Se vc conseguir fazer isso com o PLUGIN, maravilha, eu jogo a VM da M$ no lixo agora.

Olá

Isto não um requisito meio estranho em um ambiente http? E se a tal outra página nunca for aberta o recurso não será um desperdício igual ou pior do que um memory leak?

[]s
Luca

Realmente vc levantou um bom ponto, Luca. Não tinha pensado na coisa por esse lado.

Mas pensando agora, uma VM rodando no background de um Browser não deve pesar muito. Realmente algum espírito de porco poderia usar isso para deixar um milhão de threads rodando ali. Não sei…

Mas uma coisa vc não pode negar: Isso facilita muito a comunicação inter-applet. E cai como uma luva para algumas situações.

No meu caso, o único workaround e criar um FRAME invisível com um applet rodando ali, de forma que o applet fique ativo em todas as páginas do meu site. Nada bom ou elegante…

Olá

Além de um servlet que converse com as applets assinadas usando URLConnection, um outro workaround poderia usar JSobject para fazer a comunicação applet x JavaScript. Ver: Technical Articles and Tips JDC Tech Tips: February 19, 2002 - USING THE JSOBJECT CLASS IN APPLETS

[]s
Luca

Ola eu novamente…

Bem, isso não vem a ser estranho, como colocado acima… Se a JVM da M$ oferece este recurso por que não explorá-lo? Quanto à memória, creio que um “loopzinho” (com um sleep(…) dentro do run(), claro) não vai pesar. A menos que um programador “prego” coloque uma estrutura de dados no tamanho do mundo…

Mas a verdade é que, a pesar dos pesares, explorar esse recurso vai inviabilizar a funcionalidade total do sistema (que usa este recusro estático) para usuários que baixam e instalam o plug-in ou até mesmo aqueles que usam outro S.O, já que este é um recurso da JVM da M$. E como os bons projetistas, devemos criar soluções portáveis, mesmo porque essa é a alavanca que Java nos dá, não é?

É óbvio que existem outras formas de se chegar aos mesmos resultados proporcionados pelo Thread estático utilizando o nosso HTTP de cada dia… Um FRAME aqui… UM IFRAME ali…

Claro, existe o problema da segurança, já que um applet com 10 linhas pode derrubar uma máquina que tem uma JVM que suporta Threads estáticos. É só chamar, do applet, um Thread que cria mais 10! Assim o crescimento é exponencial… É preocupante mas isso é ooooooooooooooooooooutra estória!

Té+…

Outra coisinha… Essa parada do JSObject só roda em Windows?

Tè+…

No meu o único workaround possível é o FRAME invisível porque o que eu tenho na verdade é um socket escutando chamados num thread estático. Não tenho como conectar o socket novamente ao servidor a cada nova página, logo eu conecto ele uma vez só e depois recupero o thread em qualquer lugar do meu site.

Olá

A JVM da M$ que já foi descontinuada desde o lançamento do Windows XP não tem nenhum compromisso com o Java portanto qualquer solução baseada nela já deveria ter sido modificada desde o anúncio da M$ muito antes do lançamento do XP.

O JSObject foi criado pela Netscape e vinha com o Java no arquivo jaws.jar até a versão 1.4. Nas novas versões este jar sumiu e portanto deve ser baixado junto com um java antigo nos archives da Sun. Procure por JSObject aqui no GUJ para saber mais.

[]s
Luca