Discussion :

[biozaxx]

Bonjour,

je cherche un outil permettent d'analyser les import d'une appli java et d'extraire des jar les .class utilisés.

je m'explique : dans une appli j'utilise quelques classes des librairies commons-collections et autres
mais je ne veux pas avoir a embarquer les 300 000 jar correspondant , juste les classes dont j'ai besoin et je me disait qu'il y a certainement des outils qui analysent les besoins et créent une belle compile des jar ... car j'ai commencé a le faire a la main mais ce devient vite pénible.

j'ai été faire un tour dans la liste des outils java sur le forum mais je n'ai rien trouvé de tel.

Donc si quelqu'un a déjà vu passer quelque chose comme ca je suis preneur .

merci

@+

[adiGuba]

Salut,


Je ne sais pas si cela existe, mais cela peut poser plusieurs problèmes :

• 1. Les licences de ces jars ne t'authorise pas forcément cela.
  2. Il faudrait également analyser les codes sources de tous les jar que tu utilises pour analyser leurs dépendances (ce n'est pas parce que tu utilises seulement une classe d'un jar que les autres classes ne sont pas utilisé indirectement).
  3. Certaine classe peuvent être utilisé via l'API de reflection, ce qui fait que le lien est plus dur à faire (pas d'import dans le code source, mais le nom de la classe peut être dans un fichier de config, ou généré à l'exécution...).
  4. Il ne faut pas oublier les inner-classes et les classes anonymes...

Qu'est-ce qui te gène dans l'utilisation des jar ?

a++

[biozaxx]

et bien en fait je suis en train de créer une appli qui est lancée via java web start.
De ce fait je suis obligé de signer tous les jar utilisés par mon appli (car connexion avec une bdd) .
j'utilise par exemple la class Bidimap de commons-collections, ou encore hibernate et comme tu le fais remarquer en 2 et 3 il y a moulte jar associés à ces librairie je suis donc obliger de fournir plusieur Mo de jar pour quelques classes utilisées.

De plus je ne trouve pas tres pratique et pas propre d'avoir à signer des librairies qui ne sont pas de moi lorsque celle ci ne sont pas signées. Je voulais donc créer un seul jar contenant toute les class "externes" à mon appli.

voila c'est tout, mais ca na pas l'air specialement faisable

[Ashen-Shugar]

Salut!!

je suis tout a fais d'accord avec biozaxx...et j'aillais justement poser la meme question.

de plus quand au fait une application java les 3/4 du temps on est obligé d'avoir un grand nombre de jar qui gonflent monstrueusement le projets.

Si on veux faire une petite application légère mais qu'il faut que les utilisateur télechargent plusieurs Mo de librairies c'est pas génial.

Ca serait quand même génial si il existe un utilitaire qui génére un jar avec les classes qui ont une dépendence avec le projet.

[adiGuba]

Je ne connais pas bien le fonctionnement de Java Web Start, je ne sais pas si tu es obligé de signer tous les jar ou seulement le jar principal...

Si on veux faire une petite application légère mais qu'il faut que les utilisateur télechargent plusieurs Mo de librairies c'est pas génial.

Quel différence entre plusieurs jar et un gros jar ???
Au moins avec plusieurs jar cela te simplifie les mises à jours (il n'y a que les jar modifiés à recharger...)

a++

[romdelf]

Salut
Je suis d'accord avec les points de adiGuba.
De plus, si tu te fais un jar avec tout et n'importe quoi à l'intérieur, tu n'auras aucune structure à l'intérieur... Aucune réutilisabilité possible de ton jar d'un projet à un autre.

L'utilisation de jar est là pour aider et simplifier le travail des développeurs. Si tu as besoin de qq chose, par exemple un parsing de fichier, tu sais que tu as tel ou tel jar pour le faire (et il ne sert qu'à cela).

[zais_ethael]

Non, moi aussi je suis d'accord avec biozzax.
Il n'est pas ici question de réutilisabilité mais de solution de déploiement.
Si il existait un utilitaire capable de détecter automatiquement les dépendences de nos classes, il suffirait de l'utiliser à chaque nouvelle version. D'où un gain de place et donc une plus grande facilité de déploiement.
Pour ce qui est de l'argument des licences, ca ne tient pas.
Aucune licence, à ma connaissance, n'oblige à fournir la totalité du code de l'api. Il est généralement question d'afficher le contrat de licence, le nom des développeurs,...ect. Pour ces trucs la il faut de toutes facons faire quelques document à part.
Le problème n'est pas obligatoirement de faire un "gros jar" mais de limiter le nombre de fichiers et leurs tailles en supprimant des .class .
Moi aussi ca me plairait bien un utilitaire de ce genre.

[adiGuba]

Il n'est pas ici question de réutilisabilité mais de solution de déploiement.

Pourquoi ne pas utiliser Java Web Start pour le déployement ?

Si il existait un utilitaire capable de détecter automatiquement les dépendences de nos classes, il suffirait de l'utiliser à chaque nouvelle version. D'où un gain de place et donc une plus grande facilité de déploiement.

Mais lorsque tu dois mettre à jours ton application, tu devras tout déployer à nouveau, même si un seul jar a changé...
Le gain de place n'est vrai que pour le premier deployement... Toutes les mises à jours seront très loudres car tu redeployes tout le code à chaque fois...
Et je ne vois pas de difficulté à deployer une arborescence de fichiers (que tu peux eventuellement archiver)...

Pour ce qui est de l'argument des licences, ca ne tient pas.
Aucune licence, à ma connaissance, n'oblige à fournir la totalité du code de l'api. Il est généralement question d'afficher le contrat de licence, le nom des développeurs,...ect. Pour ces trucs la il faut de toutes facons faire quelques document à part.

Pour les licences libres peut-être (et encore je n'en suis pas sûr à 100%), mais je ne pense pas que ce soit le cas pour toutes les licences...

Le problème n'est pas obligatoirement de faire un "gros jar" mais de limiter le nombre de fichiers et leurs tailles en supprimant des .class .

Comme je l'ai dit, supprimer des fichiers *.class peut poser problème si les classes sont chargées par reflection, et ce n'est pas forcément possible de le voir...

Moi aussi ca me plairait bien un utilitaire de ce genre.

Je viens de voir qu'il y a un plugin eclipse qui permet de faire des jars 'uniques' : http://one-jar.sourceforge.net/

Par contre il ne 'supprime' pas de fichier *.class...

a++

[Ashen-Shugar]

Il n'est pas ici question de réutilisabilité mais de solution de déploiement.

Pourquoi ne pas utiliser Java Web Start pour le déployement ?

Ca change rien la taille avec Java Web Start, il faudra quand même télécharger toutes les librairies ( jar ) associé à ton application.

L'intéret du jar unique c'est surtout une taille reduite au maximum pour que cela soit plus rapide a télécharger et un emcombrement minimum(éviter des jar identique dans plusieurs applications alors qu'on en utilise une infime partie).

Pour ce qui est de mise à jour de l'application; on a toujours les sources avec les librairies jar associé. Le jar unique serait juste recréé et mis à disposition pour les utilisateurs.