Compressão de jar

3 respostas
D

Bom dia pessoal,
estou com uma dúvida em relação a compressão do jar.

Aqui na empresa temos um produto, rodando no 1.4 que é frequentemente enviado para ftp para atualização nos clientes, então brigamos direto com o tamanho dele.

O jar possui em média 30mb (gerado c/ ant 1.5).
Lendo em um blog (não lembro o link agora) dizia que se gerado o jar com compress false e depois utilizado um software de compressao (winrar, 7z) o tamanho do jar ficaria menor.

Fazendo alguns testes realmente acontece isso, de 30mb passou para 17mb, uma diferença de quase 50%.
Seria pelo fato do algoritmo de compressão usado pelo software ser melhor que o do ant?

Algumas dúvidas que acabaram surgindo foi quanto a performance da aplicação:

O jar está mais comprimido, então em algum momento ele teria que processar esta descomprensão, correto?
Senti uma diferença na hora de carregar o programa, no java -jar, ele demora um pouco mais para iniciar, seria nesse momento que ele descomprime?

Apesar de estar mais comprimido, internamente os .class estão maiores, teria diferença de performance na hora de carregar as classes? Ocuparia mais memória?

No caso teríamos benefício na hora de subir o jar para os clientes pois o tamanho está pela metade, mas será que esta alteração prejudicaria na performance?

Se alguém tiver algum material relacionado ao assunto pode mandar…

Desde já agradeço.

3 Respostas

T

Amigo, um arquivo jar que foi comprimido pelo 7Z, RAR ,ou mesmo pelo próprio WinZip não pode ser rodado diretamente. Ele deve ser descomprimido pelo 7Z, RAR etc.

O que eu faria no seu lugar (solução 100% Java):

http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/pack200.html

a) Compactaria o jar com pack200.exe - isso gera um arquivo .pack.gz
b) No cliente, descompactaria o jar com unpack200.exe (que deve ser enviado para seu cliente).

O arquivo unpack200.exe vem com o JDK e pode ser redistribuído sem problemas.

T

De qualquer maneira, o JAR compactado ou descompactado ocupa exatamente o mesmo espaço na memória, já que a JVM sempre descompacta os bytecodes quando vai carregar a classe. Ou seja, talvez você tenha uma alteração de desempenho para melhor se mandar o JAR descompactado (opção -0 do jar).

D

Thigol, primeiramente obrigado pela atenção.

Quanto ao esquema do pack200 eu já tinha visto e seria uma ótima, porém como na maioria dos casos a atualização é feita pelo próprio cliente (sobrescrevendo os jars) não queria colocar mais uma etapa (unpack).

A minha dúvida seria mesmo quanto ao carregamento por parte da VM…
Se eu gero um jar SEM compress, os .class ficam maiores, porém não teria perda de processamento com descompressão por parte da VM, certo? Porém achava que demoraria mais pra carrega-los e ocuparia mais espaço em memória.

Mas como você disse:

No caso então a VM descompacta o class, ficando sempre com o mesmo tamanho… então compensaria deixar sem compress mesmo…

É que também tivemos um problema nesse projeto, pois existiam uns menus gigantescos criados apartir de inner class (uma inner pra cada item do menu)…
O acesso a disco ia lá pro alto e demorava um tempo consideravel pra abrir o menu…

Por isso resolvi vir tirar esta duvida…

Obrigado!!

Criado 19 de janeiro de 2010
Ultima resposta 19 de jan. de 2010
Respostas 3
Participantes 2