Não deixar executar dois sistemas

acho que você vai ter de procurar nas apis, talvez seu programa fique menos portátil por causa disso

Bom,

A maneira mais gambiarra é abrir um socket e “escutar” em uma porta

Assim, quando o usuário tentar iniciar denovo a mesma aplicação, gerará uma exceção pois a porta já estará ocupada. Dê um catch nela e saia da aplicação !

Abraços,
Bruno Carvalho

se é para fazer gambiarra, grava em um arquivo que ele já está aberto

Ah, mas se der algum problema e a aplicação fechar sem remover essa entrada no arquivo, ele nunca mais abre a aplicação denovo hehehehe.

Abraços,
Bruno Carvalho

aí vc cobra manutenção e arruma o arquivo

hahahahahah :shock:

bmentges:

Bom,

A maneira mais gambiarra é abrir um socket e “escutar” em uma porta

Assim, quando o usuário tentar iniciar denovo a mesma aplicação, gerará uma exceção pois a porta já estará ocupada. Dê um catch nela e saia da aplicação !

Abraços,
Bruno Carvalho

gambiarra? porque!? ué, faz esse socket aceitar alguns comandos e puxa, vc tem uma funcionalidade nova no sistema!!

heheh

abraços

Hmmm… já teve uma pergunta dessas, mas acho que durante o pau do guj ela foi perdida.

O problema de você abrir uma porta é que você não sabe se ela é usada de verdade por outra aplicação (além disso, abrir uma porta no windows é fazer um furo num queijo suíço)
Muitos programas (firefox, eclipse, …), ao invés disso, usam um arquivo de lock mesmo.

É só colocar isso no main:

try{ new ServerSocket( 8888 ); }catch( IOException e ){ System.exit( 0 ); }
pá-pum

cesarse:

Hmmm… já teve uma pergunta dessas, mas acho que durante o pau do guj ela foi perdida.

O problema de você abrir uma porta é que você não sabe se ela é usada de verdade por outra aplicação (além disso, abrir uma porta no windows é fazer um furo num queijo suíço)
Muitos programas (firefox, eclipse, …), ao invés disso, usam um arquivo de lock mesmo.

daria pra resolver isso se você alterar o arquivo em 1 em 1 segundo, assim, você poderia checar isso na inicialização, se o timestamp do arq fosse > que 1 segundo, significa q o programa fechou de forma inesperada

num da?

Deve haver uma maneira mais simples… por enquanto a do sokets tá ganhando, hehe…

peron:

daria pra resolver isso se você alterar o arquivo em 1 em 1 segundo, assim, você poderia checar isso na inicialização, se o timestamp do arq fosse > que 1 segundo, significa q o programa fechou de forma inesperada

num da?

E a performance do programa vai pro saco ne ?

I/O assim nao rola

Abraços,
Bruno Carvalho

Experimenta derrubar (kill -9) seu eclipse e vê se ele vai iniciar sozinho. É algo que a gente tem que conviver. :shock:

O gnome também dá pau às vezes, aí tem que sair caçando o arquivo de lock pra apagar. Ah! O firefox também.

Talvez algum algoritmo sofisticado resolva. Ou talvez dê pra provar que não há solução, mas que dá pra fazer algo que funcione em 99,95% dos casos (não dá pra pensar nisso agora).

Você pode fazer isso ou, no futuro, lançar um patch da sua aplicação porquê descobriram uma falha de segurança que explora essa porta escancarada.

editado
E se você tentar abrir o arquivo para gravação? Seria a mesma idéia do socket, mas usando arquivos para aproveitar o lock do sistema operacional.
Se um segundo processo tentar abrir, não consegue. Se o primeiro processo morrer anormalmente, o arquivo .lock vai existir mas vai ter permissão de gravação, significando que não tem processo rodando.

Uma alternativa é obter um lock de um arquivo e caso o usuário tente abrir outra instância do programa peça que ele confirme se não há outra instância já aberta.

Isso resolve o problema do programa encerrar anormalmente, porém exige que o usuário confirme uma operação (e a maioria ignora diálogos de aviso).

Bem… realmente o arquivo parece ser mais seguro…

Bom, o socket parece interessante realmente, mas eu voto tentar travar um arquivo.

Você abre um FileInputStream, dá um getChannel() e com o objeto da classe FileChannel (java.nio.channels), manda um lock() no bichinho.

Agora é só escolher…

[edit]Respoderam enquanto escrevia…

Bom, essa de derrubar na marra o processo é algo radical e que não deve acontecer normalmente… mas mesmo assim achava que o SO destravava o arquivo

Destrava, mas não apaga.
Por isso não dá só pra ver se existe um arquivo de lock. Tem que tentar escrever nele.
Eu não conheço essas classes que você falou. Vou ler o javadoc pra ver se tem mais coisas interessantes nesse pacote…

bom, se destrava, então é só parar o programa quando não puder travar nesse arquivo.

no fim do programa vc apaga ele, que pode ser um arquivo vazio mesmo, só pra ter ele ali.

e se ele existir no início da execução e você puder travar mesmo assim, ainda você pode dar uma mensagem de que a última execução não foi corretamente fechada, e iniciar uma rotina de restauração do sistema, tipo quando o word trava e ele volta com o que vc vinha digitando, olha que chique! hahahaha

flw