Ma petite bibliothèque de logiciels doit-elle éviter d'utiliser d'autres bibliothèques?

Je viens de publier une petite bibliothèque Java qui ne propose que quelques classes et méthodes. Depuis que j'ai construit le projet avec Maven, j'ai immédiatement utilisé plusieurs bibliothèques tierces pour atteindre mes objectifs, notamment:

commons-lang3 (pour certaines choses Java générales)
slf4j-api (pour la journalisation)
commons-io (pour un tout petit peu de trucs sur les fichiers - lire un fichier littéralement une fois, je pense)

Je ne veux pas que ma bibliothèque apparaisse gonflée aux yeux des autres. Dois-je essayer de supprimer ma dépendance à ces bibliothèques pour minimiser mon empreinte? Des conseils sur les types de bibliothèques qu'il serait préférable d'éviter lorsque vous envisagez d'en utiliser davantage à l'avenir?

java libraries maven

— Duncan Jones
source

une partie concrète de votre question semble répondre: votre projet plus des bibliothèques concrètes plus si c'est OK. Le problème est que vous l'avez épelé avec la partie générale "devrait ... petit ... éviter". Dans l'état actuel des choses, cette question ne convient pas à notre format de questions / réponses. Nous nous attendons à ce que les réponses soient étayées par des faits, des références ou une expertise spécifique, mais cette question suscitera probablement un débat, des arguments, des sondages ou une discussion approfondie. Si vous pensez que cette question peut être améliorée, consultez la FAQ pour obtenir des conseils.

— moucher

@gnat Mes excuses. En tant qu'utilisateur régulier de Stack Overflow, j'avais eu tendance à supposer que les questions légèrement subjectives étaient acceptables sur les programmeurs. Existe-t-il un site Stack Exchange où de tels problèmes sont OK? En attendant, je supprimerai tout flou de ma question.

— Duncan Jones

@gnat Cette question est très bien, même dans sa forme originale.

— Thomas Owens

@ThomasOwens avec tout le respect que je vous dois, je ne le pense pas; pour la version originale, j'ai rapidement trouvé deux réponses avec des recommandations opposées, toutes deux raisonnablement justifiées: bienvenue au jeu de sondage

— gnat

@gnat Seulement deux? C'est très bien. Qu'ils soient affichés et votés. Deux réponses potentiellement correctes avec justification et raisonnement opposés ne rendent pas la question mauvaise. Ni 3, ni 4, ni même 5. C'est une question bien posée qui est un problème auquel les développeurs de bibliothèques doivent faire face, et le fardeau est alors mis sur les réponses pour être de bonnes réponses .

— Thomas Owens

Réponses:

Je réponds à cela compte tenu de votre situation particulière. Je dirais que c'est bien d'utiliser ces bibliothèques. Assurez-vous simplement que votre slf4j-api n'apporte pas l'implémentation avec. J'entends par là marquer la dépendance d'implémentation comme "test". PAR EXEMPLE:

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-log4j12</artifactId>
    <version>1.7.2</version>
    <scope>test</scope>
</dependency>

Ceci est décrit en détail dans la FAQ SLF4j.

Quant aux deux autres, IME, ils sont toujours rétrocompatibles. Par conséquent, si dans 5 ans, j'ai besoin d'utiliser votre bibliothèque mais que vous en utilisez une ancienne version, je peux simplement exclure vos dépendances et notre code fonctionnera toujours. En d'autres termes, en utilisant ces bibliothèques spécifiques, vous n'introduirez pas jar-hell pour les autres.

Si j'utilise votre bibliothèque via maven, je ne remarquerai pas si votre bibliothèque est gonflée ou non. Je vais juste dépendre du vôtre et l'utiliser. Je pense qu'il est plus important que votre code fonctionne correctement que son encombrement est plus petit. Je préfère que vous utilisiez commons-io au lieu de réinventer la roue avec un bug.

— Daniel Kaplan
source

Merci pour la réponse, je pense que nous sommes globalement d'accord sur l'approche que je dois adopter. Juste pour corriger un bit - la façon dont on devrait inclure slf4j dans un projet de bibliothèque est d'inclure simplement slf4j-apiet aucun autre artefact connexe, fourni ou non. Voir slf4j.org/manual.html#projectDep .

— Duncan Jones

Je me souviens de quelques exercices cérébraux (zillions de excludes iirc) que j'ai dû faire quand des modules particuliers dans mes dépendances ne pouvaient pas "s'accorder" sur une version slf4j. D'après votre réponse, il semble que si les concepteurs de modules l'exposeraient provided, il n'y aurait pas de problèmes comme celui-ci, n'est-ce pas?

— moucher

@gnat Normalement, cela serait résolu (au moins dans Maven), en déclarant une version préférée dans votre POM. Maven prend la version "la plus proche" définie pour un artefact et le POM immédiat l'emporte sur les dépendances transitives. Il s'agit peut-être d'un changement de comportement lors d'une version Maven 2.x.

— Duncan Jones

+1 pour avoir spécifié slf4j comme provided- très discret.

— Gary Rowe

@DuncanJones merci, j'ai probablement raté ça à l'époque. Ma version de maven était 2.2 ou 2.3, je ne me souviens pas laquelle (bien que je me souvienne bien comment mvn dependency:analyzeapportait des versions de merde jusqu'à leur exclusion :)

— gnat

Non.

"Ballonnement" est un mythe. Peu importe la quantité de code dans votre bibliothèque, si une partie de ce code n'est jamais utilisé, il ne sera pas paginé - il n'aura aucun impact sur les performances ou l'empreinte mémoire.

D'un autre côté, si vous avez besoin de cette fonctionnalité supplémentaire, vous avez deux choix. Vous pouvez soit l'écrire vous-même et consacrer beaucoup de temps et d'efforts à résoudre des problèmes que d'autres ont déjà résolus auparavant, ou vous pouvez choisir d'utiliser la solution qui existe déjà (et qui a été testée / déboguée / etc.).

Cela nous laisse avec la taille du téléchargement et l'empreinte de l'espace disque, et à moins que vous ne parliez de chiffres stupides, en 2013, ce sont deux facteurs qui devraient être proches du bas de la liste des choses dont vous devez vous inquiéter.

— Maximus Minimus
source