Apesar de todas as polêmicas sobre Java, não dá para desmerecer o que a linguagem e seu ambiente de execução podem fazer, especialmente o JavaFX, voltado a RIA. O JavaFX 2.2 permitirá empacotar os apps criados por ele (que também rodam com o Java convencional) na forma de aplicativos tradicionais, independentes. Isso facilitará a redistribuição, tornando os apps algo mais próximo ainda de um programa desktop completo e independente.
Os pacotes podem ser gerados para cada plataforma: um .dmg para OS X, .exe ou .msi para Windows e .rpm ou zip para Linux.
Exemplo do pacote de instalação nativo no OS X
Exemplo do pacote de instalação nativo para Windows, usando o Inno Setup
Os arquivos necessários de runtime farão parte do pacote, e o processo será visto como um processo independente – seuaplicativo.exe em vez de java.exe, por exemplo.
Isso tem lá suas vantagens e desvantagens. Todos os métodos atuais de distribuição não serão afetados; empacotar os apps Java é apenas uma nova possibilidade. Apesar do arquivo ficar maior, em geral será mais simples para os usuários.
Dessa forma o programa final não dependerá de uma instalação do Java. Os apps poderão ser instalados por usuários comuns, sem acesso administrativo. No caso do Mac fica facilitada a redistribuição pela App Store, já que lá o app deve ser completo (sem depender de bibliotecas instaladas à parte, algo que a Apple não gosta).
Quem prefere não manter o Java instalado devido seu grande histórico de falhas de segurança também poderá usar tais apps. Como os arquivos de runtime estarão empacotados com o app em si, o uso é exclusivo do app em questão. A atualização não será automática, ficando dependente do programador. As falhas de segurança aparentemente não serão um problema justamente por rodar isolado. Um outro .jar qualquer ou um applet num site da internet não terá como acessar estas bibliotecas para funcionar, eles continuarão requerendo a instalação do Java tradicional. A menos que o app distribuído seja malicioso, fica difícil imaginar grandes abusos, diferente do Java comum que pode colocar o computador em risco apenas por visitar um site.
Um ponto a favor da versão fixa (sem atualização automática) é que o desenvolvedor terá garantias de que seu app roda com a versão do Java com o qual foi empacotado. Diferentes programas poderão ter diferentes versões das bibliotecas/runtime rodando no mesmo computador.
A Oracle trabalha na otimização dos arquivos para empacotamento. O pacote final será maior do que o jar isolado, mas os benefícios com a integração podem fazer valer a pena.
Para os usuários a ideia é que os aplicativos se comportem como aplicativos, não como conteúdo em Java que depende do ambiente de execução.
Há instruções e mais informações no blog de desenvolvimento do Java.
Esta postagem foi modificada pela última vez em 19/06/2012 20:12