Etude des dépendances de jTimer 1.5.x
Bonjour, jTimer étant toujours trop gros (> 7 Mo zippé) par rapport à ce qu'il fait, voici l'état des dépendances et des possibilités d'amélioration. Par taille de dépendance: - freemarker (1,4Mo) : utile pour les rapport, mais voir pour utiliser mustache à la place ? - swingx-core (1.2Mo) : librairie sous utilisées, mais quand même quelques composant difficile à remplacer - jna (1.1Mo) : pas possible de faire mieux à cause du code natif (so, dll) des plateformes cibles - log4j-core (1.1Mo) : c'est gros pour ce que c'est, voir pour un remplacant ? logback (450k) ? - commons-collection4 (600k) : dépendance de nuiton-config - commons-collection (600k) : dépendance de nuiton-config - commons-lang3 (450k) : on doit pouvoir s'en passer avec java 8, mais ... dépendance de nuiton-config - nuiton-utils : dépendance de nuiton-config - commons-beanutils: dépendance de nuiton-config - commons-io: pourrait ne pas être utilisée, mais fonctions bien pratique car la File API de java 7 a des manques - nuiton-config: utile pour ApplicationConfig - (et il en reste) -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
On Mon, 29 Feb 2016 15:32:13 +0100 Eric Chatellier <chatellier@codelutin.com> wrote:
Bonjour,
jTimer étant toujours trop gros (> 7 Mo zippé) par rapport à ce qu'il fait, voici l'état des dépendances et des possibilités d'amélioration.
Je ne comprends pas le problème que pose la taille du projet. Dans quel cas précis cela est-il un problème ? tony. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: chemit@codelutin.com twitter: https://twitter.com/tchemit
Je ne comprends pas le problème que pose la taille du projet.
Dans quel cas précis cela est-il un problème ? Dans la perception qu'ont les utilisateurs lors du téléchargement d'un outil (un
Le 29/02/2016 16:12, Tony Chemit a écrit : petit outil, cela doit être léger). La seule chose qui nous bloque encore pour jTimer 2 par exemple, c'est la taille des binaires qui est de 80 Mo par exemple. Et dans la vision développeur, c'est moyen: - d'utiliser une classe dans une lib et d'avoir 4 ou 5 dépendances inutiles - d'utiliser une lib qui dépasse le Mo pour peut de fonctionnalités. -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
On Mon, 29 Feb 2016 18:39:23 +0100 Eric Chatellier <chatellier@codelutin.com> wrote:
Je ne comprends pas le problème que pose la taille du projet.
Dans quel cas précis cela est-il un problème ? Dans la perception qu'ont les utilisateurs lors du téléchargement d'un outil (un
Le 29/02/2016 16:12, Tony Chemit a écrit : petit outil, cela doit être léger).
Je pense que c'est ta vision de la chose, qui n'est partagé par pas grand monde ? Au final j'ai l'impression que tu crées le problème ? On n'est pas dans une télévision où chaque octet est important... enfin qu'on dit :(
La seule chose qui nous bloque encore pour jTimer 2 par exemple, c'est la taille des binaires qui est de 80 Mo par exemple.
Euh non dans JTimer 2 moi y'a bien autre chose avant la taille du projet qui me bloque, genre le code... :(
Et dans la vision développeur, c'est moyen: - d'utiliser une classe dans une lib et d'avoir 4 ou 5 dépendances inutiles - d'utiliser une lib qui dépasse le Mo pour peut de fonctionnalités.
Je ne te rejoins pas, le développeur n'a pas à se soucier des dépendances qui sont tirées; si la fonctionnalité qu'il recherche y est, la phase de réduction du code utilisé ne doit pas être faite à ce moment mais au moment de la production du livrable. Si tu as vraiment envie d'investiguer sur le sujet, supprimer comme tu les fais des dépendances transitives n'est vraiment pas une bonne idée. Cherche plutôt un plugin maven qui te restitue dans un jar que les classes utilisées par ton code ça me parait nettement plus optimisé! Car j'ai envie de suivre ton raisonnement et te de demander : À quoi bon utiliser une librairie sans dépendance juste pour une classe ? mieux vaut dupliquer la classe dans ton projet (ce qui est le pire à faire AMTHA). My 2 cents, tony. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 http://www.codelutin.com email: chemit@codelutin.com twitter: https://twitter.com/tchemit
Le 29/02/2016 23:15, Tony Chemit a écrit :
Cherche plutôt un plugin maven qui te restitue dans un jar que les classes utilisées par ton code ça me parait nettement plus optimisé!
Genre proguard. Mais oui, c'est typiquement un truc qu'on utilise pour faire des applis Android, pas desktop... Arnaud
En théorie, exclure les dépendances transitives que tu n'utilises pas ne pose pas de problème. Tu pourrais diminuer drastiquement la taille de l'appli je pense, mais tu sais à quoi tu t'exposes (risques de ClassNotFound si tu as exclu une dépendance en trop), à toi de voir. Personnellement, je rejoins l'avis de Tony : >7Mo, ça n'a rien de choquant. Si j'étais toi, je dépenserai mon énergie dans d'autre chantiers. ++ Arnaud Le 29/02/2016 15:32, Eric Chatellier a écrit :
Bonjour,
jTimer étant toujours trop gros (> 7 Mo zippé) par rapport à ce qu'il fait, voici l'état des dépendances et des possibilités d'amélioration.
Par taille de dépendance: - freemarker (1,4Mo) : utile pour les rapport, mais voir pour utiliser mustache à la place ? - swingx-core (1.2Mo) : librairie sous utilisées, mais quand même quelques composant difficile à remplacer - jna (1.1Mo) : pas possible de faire mieux à cause du code natif (so, dll) des plateformes cibles - log4j-core (1.1Mo) : c'est gros pour ce que c'est, voir pour un remplacant ? logback (450k) ? - commons-collection4 (600k) : dépendance de nuiton-config - commons-collection (600k) : dépendance de nuiton-config - commons-lang3 (450k) : on doit pouvoir s'en passer avec java 8, mais ... dépendance de nuiton-config - nuiton-utils : dépendance de nuiton-config - commons-beanutils: dépendance de nuiton-config - commons-io: pourrait ne pas être utilisée, mais fonctions bien pratique car la File API de java 7 a des manques - nuiton-config: utile pour ApplicationConfig - (et il en reste)
En théorie, exclure les dépendances transitives que tu n'utilises pas ne pose pas de problème.
Tu pourrais diminuer drastiquement la taille de l'appli je pense, mais tu sais à quoi tu t'exposes (risques de ClassNotFound si tu as exclu une dépendance en trop), à toi de voir. maven-shader-plugin fonctionne, il réduit l'application à 3.8Mo, mais demande
Le 29/02/2016 21:22, Arnaud Thimel a écrit : trop de configuration et trop de maintenance à long terme parce qu'il faut faire quelques exclusion sur les parties "runtime" du classpath.
Personnellement, je rejoins l'avis de Tony : >7Mo, ça n'a rien de choquant. Si j'étais toi, je dépenserai mon énergie dans d'autre chantiers.
Ca me gêne fondamentalement, pas pour la taille finale, mais parce qu'on utilise des dépendances mal sélectionnées ou mal designées.
Le 29/02/2016 15:32, Eric Chatellier a écrit :
Par taille de dépendance: - freemarker (1,4Mo) : utile pour les rapport, mais voir pour utiliser mustache à la place ?
Je vais remplacer le veillissant freemarker par mustache, aussi parce que l'API a été mise à jour pour java 8. -- Éric Chatellier - www.codelutin.com - 02.40.50.29.28
participants (3)
-
Arnaud Thimel -
Eric Chatellier -
Tony Chemit