Não consigo iniciar aplicativos JNLP usando o “Java Web Start”?

Até recentemente, eu era capaz de iniciar / abrir arquivos JNLP no Firefox usando o Java web start .

Não sei o que aconteceu de repente arquivos JNLP parou de lançar, aparece uma canvas inicial dizendo Java Starting … e, em seguida, nada acontece. Mesmo o Java Console no navegador e o applet javacpl.cpl não abrem.

Tentei todas as possibilidades: removido toda a versão mais antiga e instalado o mais recente JRE (versão java “1.6.0_17”), ainda assim não funciona.

Feito alguns googling para este problema, as pessoas sugeriram para iniciar javaws.exe com opção de -viewer, mas mesmo comportamento (uma canvas inicial aparece dizendo “Java Starting …” e depois desaparece)

O problema é que eu não conheço nenhum lugar (logs etc.) para procurar o que está causando o problema.

Estou usando o WinXP SP3 e algumas das capturas de canvas abaixo mostram mais informações sobre o meu sistema. Eu posso fornecer qualquer outro detalhe, se necessário, mas por favor me ajude a resolver este problema.

Eu sei que esta é uma pergunta antiga, mas na semana passada eu comecei a ter um problema semelhante, então deixo aqui algumas notas sobre a solução que me serve.

Isso aconteceu apenas em algumas máquinas do Windows usando até o último JRE até a data (1.8.0_45).

O Java Web Start começou a carregar, mas nada aconteceu e nenhuma das tentativas de solução anteriores funcionou.

Depois de algumas escavações eu encontrei este segmento, que dá a mesma configuração e uma ótima explicação.

https://community.oracle.com/thread/3676876

Então, em conclusão, foi um problema de memory no x86 JRE e como o heap máximo do nosso JNLP foi definido como 1024MB, nós mudamos para 780MB como sugerido e foi corrigido.

No entanto, se você precisar de mais de 780 MB, poderá sempre tentar iniciar em uma versão x64 do JRE.

Dê uma olhada no que acontece se você executar javaws.exe diretamente da linha de comando.

Eu tive o mesmo problema aqui. vá para o painel de controle e configurações do seu java … desmarque “Manter arquivos temporários da Internet no meu computador”. Aplique as alterações e tente novamente o seu .jnlp

Nota: Testado em diferentes máquinas; Windows Server 2012, Windows Server 2008 e Windows 7 de 64 bits. Versão Java: 1.7 ++ desde o meu aplicativo jnlp é construído em 1.7

Por favor, deixe-me saber o seu feedback também. : D

Embora essa questão seja um pouco antiga, o problema foi causado por uma configuração de registro do ClearType corrompida e foi resolvida corrigindo-a, conforme descrito neste ClearType, install4j e no caso do bug post de Java .

ClearType, install4j e caso do bug Java Java

Você sabe o que o ClearType (tecnologia de suavização de fonts no Windows) tem em comum com o Java (linguagem de programação e uma das estruturas recomendadas)?

Nada, exceto que eles estavam trabalhando juntos para me deixar infeliz por alguns meses. Eu tinha alguns softwares Java que não consegui instalar. Quero dizer realmente não poderia – nem mesmo descobrir o motivo ou reproduzi-lo em outro PC.

Recentemente fui aprovado para o beta do Woopra (serviço de análise do site) e ele usa um cliente de desktop escrito em Java… eu não consegui instalar. Isso me deixou muito bravo. 🙂

História Todo o software em questão foi semelhante:

configuração baseada em install4j; instalação travando com um monte de erros. Eu estava culpando o install4j durante as primeiras tentativas (cem ou mais) para resolver o problema. Mais tarde, eu lentamente entendi que, se fosse esse bug por tanto tempo – a solução teria sido criada e pesquisada.

Rastreamento Depois de mudar o foco do install4j, decidi empurrar o framework Java. Eu estava tentando versões estáveis ​​anteriormente, então decidi ir para o Update Update 10 não estável.

Isso realmente fixa mensagens de erro, mas não trava. Eu também notei que havia um novo log de erros criado no diretório com arquivos de instalação. Anteriormente, eu só tinha visto logs no diretório temporário do Windows.

Novo log de erros estava dizendo a seguir:

Não foi possível exibir a GUI. Esta aplicação precisa de access a um servidor X. Se você tiver access, provavelmente há uma biblioteca X em falta. ************************************************** ***************** Você também pode executar este aplicativo no modo de console sem access a um servidor X, passando o argumento -c Muito estranho para procurar o X-Server no Linux não PC, não é? Então eu decidi tentar esse argumento “-c”. E foi realmente capaz de instalar no modo de console.

Final feliz? Não. Agora o aplicativo instalado estava falhando. Mas isso realmente me fez pensar. Se o console funciona, mas a interface gráfica não – deve haver um problema com o último.

Mais um log de erros (na pasta do aplicativo) agora estava dizendo (entre outras coisas):

Causada por: java.lang.IllegalArgumentException: -60397977 incompatível com a tecla de contraste do LCD específica do texto Que me consultou com êxito a descrição do bug com o Java incapaz de ler a configuração de registro ClearType não padrão.

Solução Eu imediatamente iniciei o ClearType Tuner no Painel de Controle e encontrei a configuração mostrando o número de texto sem sentido. Depois de corrigi-lo corretamente, todos os problemas com Java desapareceram instantaneamente.

cleartypetuner_screenshot Lições aprendidas Não seja rápido em culpar os problemas de software em um único aplicativo. Mesmo configurações menores e totalmente não relacionadas podem iniciar reações em cadeia mortais. Links do Jave Runtime Environment http://www.java.com/en/download/index.jsp

Sintonizador ClearType http://www.microsoft.com/windowsxp/downloads/powertoys/xppowertoys.mspx

Woopra http://www.woopra.com/

install4j http://www.ej-technologies.com/products/install4j/overview.html

Se o javacpl não abrir e der a você Não foi possível encontrar a class principal :, pode ser que o Java seja confundido devido a mudanças no C:\Users\\AppData\LocalLow\Sun\Java\Deployment on Win7 deployment.properties (pode ser encontrado em C:\Users\\AppData\LocalLow\Sun\Java\Deployment on Win7 ). Apague esse arquivo e está tudo bem.

Este bug parece ter 6 anos, cf. Um aplicativo deve ser capaz de ignorar propriedades que se tornaram obsoletas com o tempo, não deveria?

Eu também estava enfrentando o mesmo problema. Para corrigir isso nas etapas a seguir.

  1. Abra o Javaws a partir do comando cmd runnig javaws -viewer. Uma nova janela se abrirá
  2. Selecione o arquivo jnlp desejado e clique no botão de execução.
  3. Feche a janela do visualizador javaws.

Este é um aplicativo para o qual você tem o código? O Java 6u14 incluiu uma mudança na maneira como ele manipula a segurança jar que, para nós, causou problemas muito semelhantes. Se os seus jars forem assinados e trabalharem com o Java 6u13 ou inferior, considere a possibilidade de refatorar seu código para contornar essa atualização ou exigir o Java 6u13 ou inferior. Infelizmente não me lembro exatamente o que fizemos para resolver o problema – era o modo de pânico na época.

Novamente, se você tiver o código, você tem ferramentas para trabalhar. Você pode colocar em instruções System.out.println em suas rotinas de boot – qualquer saída do console é exibida na janela de comando quando você executa o JNLP a partir da linha de comando. Caso contrário, você pode considerar o uso de um bom logger como log4j para ter uma idéia melhor do ponto de falha.

Você também pode considerar remover completamente o aplicativo e baixá-lo novamente. O Java Web Start possui um miniaplicativo do Painel de Controle que permite que você veja a URL da qual seu aplicativo está sendo baixado (pode ser o errado), desinstale o aplicativo, defina opções de segurança, etc.

Eu tive o mesmo problema. Descobriu-se que o tamanho de heap máximo foi definido como 1024 e faltando a unidade. A configuração precisava ser max-heap-size = 1024 m .

Portanto, a configuração de memory aparentemente inválida no arquivo jnlp causará esse comportamento exato.

No meu caso, o problema foi causado por iniciar meu aplicativo a partir de um atalho na área de trabalho pública (windows 7). Como resultado, até onde eu sei, a localização dos arquivos temporários foi definida como c: \ users \ public \ etc. Isso resultou na impossibilidade de gravar em detalhes do cache. Quando eu redefinir para os padrões no applet de controle de arquivos temporários, tudo funcionou bem.

No meu caso, o Netbeans cria automaticamente um arquivo .jnlp que não funciona e meu problema foi devido a uma substituição acidental do arquivo launch.jnlp no servidor (pela versão inadequada e incorreta do NetBeans). Isso causou uma incompatibilidade entre o arquivo .jnlp local e o arquivo .jnlp remoto, resultando no Java Web Start sendo encerrado após “Verificando o aplicativo”.

Portanto, ninguém mais precisa perder uma hora para encontrar um bug que deve ser comunicado adequadamente (mas não é) pelo Java WS.

Isso também pode ser devido à variável de ambiente CATALINA_HOME no seu sistema. Em nossa organização, houve vários casos em que os aplicativos JNLP apenas se recusaram a iniciar sem registrar nada e o esvaziamento de CATALINA_HOME resolveu o problema.

Eu tinha a variável de ambiente definida no prompt de comando e não apareceu na GUI. Não tenho certeza se o comando setx ou os comandos de remoção de registro fizeram o truque. A reboot parece ser necessária após a remoção da variável.