Para refletir sobre .jar

Acho q sim …

Seria o mesmo q vc ao precisar de um DLL ( para Delphi por exemplo ) e ao inves disso, pegar seu fonte e colocar dentro do projeto…

2 coisas ruins com esta atitude:

:arrow: Seu JAR ficaria gigantesco, ficando xarope de distribuir…
:arrow: Caso vc precisasse alterar a versao de um determinado componente, nao bastaria apenas ter q trocar o JAR do mesmo…

Por favor, me corrijam c eu estiver errado

pecado.

de acordo com Dante os descompactadores de jars ficam no VII circulo do inferno, jutamente com assaltantes, tiranos, blasfemios e outros. nada bom.

A primeira coisa que eu respondi a mim mesmo também foi pecado.

Mas e quando o jarzão ainda for pequeno?

E quando a uma aplicacação vá para um usuário leigo? Um jarzão não eliminaria a necessidade de um .bat ou .sh? E se for um applet ou uma aplição distribuída com Web Start?

E se o código continuar separado e for fundido (com ant) só na hora de criar o .jar?

Partindo-se do principio q um “usuario leigo” utiliza Windows, vc nao precisara de um BAT, basta mandar seu JAR e as dependencias dentro de uma pastinha chamada LIB por exemplo… Entao, c vc setar seu Manifest.mf direitinho, vai bastar o cara dar um duplo clique no seu JAR q o programa funciona…

no maximo use uma dessas coisas como o classworld (era esse o nome?) que jareia os jars num unico jar, mas eles estao la dentro separados e ele usa o proprio classloader para que funcione.

Olá

Pecadíssimo!

Com JavaWebStart ou com applets, o ideal é que os jars sejam os menores possíveis justamente para diminuir o tamanho dos downloads dos upgrades. Faça um monte de jars mas organize justamente tendo em mente a facilidade de upgrade porque este é o diferencial positivo do Java.

As bibliotecas de terceiros tipo log4j, xerces-impl, etc. jamais devem ser modificadas porque senão fica completamente xarope fazer upgrade delas. Como algumas bibliotes de terceiros as vezes precisam de upgrade urgente por questões de segurança então não se abre elas.

Uma coisa que se pode fazer as vezes é justamente o contrário, isto é, fazer upgrade somente dos arquivos class modificados e garantir que os novos serão usados. Isto exige um trabalhinho tanto no cliente como no servidor.

Importante: em todos os casos não se deve permitir o upgrade automático de todos os clientes ao mesmo tempo pois não há largura de banda que aguente isto. É sempre bom bolar um esquema de upgrade seletivo de clientes com escalonamento de data e horário. Isto é perfeitamente possível como o FLin pode testemunhar.

[]s
Luca