La mia piccola libreria software dovrebbe evitare di usare altre librerie?

Ho appena rilasciato una piccola libreria Java che offre solo poche classi e metodi. Da quando ho realizzato il progetto con Maven, ho immediatamente utilizzato diverse librerie di terze parti per raggiungere i miei obiettivi, in particolare:

commons-lang3 (per alcune cose Java generali)
slf4j-api (per la registrazione)
commons-io (per un po 'di roba da file - letteralmente leggere un file una volta, penso)

Non voglio che la mia biblioteca appaia gonfia agli occhi degli altri. Dovrei provare a rimuovere la mia dipendenza da queste librerie per ridurre al minimo la mia impronta? Qualche consiglio su quali tipi di librerie sarebbe meglio evitare quando si considera di usarne di più in futuro?

java libraries maven

— Duncan Jones
fonte

una parte concreta della tua domanda sembra rispondibile: il tuo progetto più libs concrete più se è OK Il problema è che l'hai scritto insieme alla parte generale "dovrebbe ... piccolo ... evitare". Allo stato attuale, questa domanda non è adatta al nostro formato di domande e risposte. Ci aspettiamo che le risposte siano supportate da fatti, riferimenti o competenze specifiche, ma questa domanda solleciterà probabilmente dibattiti, argomenti, sondaggi o discussioni estese. Se ritieni che questa domanda possa essere migliorata, consulta le FAQ per assistenza.

— moscerino del

@gnat Le mie scuse. Come normale utente di Stack Overflow, avevo la tendenza ad assumere domande leggermente soggettive accettabili per i programmatori. Esiste un sito Stack Exchange in cui tali problemi sono corretti? Nel frattempo, rimuoverò qualsiasi vaghezza dalla mia domanda.

— Duncan Jones,

@gnat Questa domanda va bene, anche nella sua forma originale.

— Thomas Owens

@ThomasOwens con tutto il rispetto, non credo; per la versione originale ho rapidamente immaginato due risposte con raccomandazioni opposte, entrambe ragionevolmente giustificate: benvenuto sondaggio

— moscerino

@gnat Solo due? Va bene. Lascia che vengano pubblicati e votati. Due risposte potenzialmente corrette con giustificazioni e ragionamenti opposti non rendono la domanda sbagliata. Né 3 o 4 o anche 5. È una domanda ben formata che è un problema che gli sviluppatori di librerie devono affrontare, e l'onere è quindi posto sulle risposte per essere buone risposte .

— Thomas Owens

Risposte:

Sto rispondendo a questo considerando la tua situazione specifica. Direi che va bene usare quelle librerie. Assicurati solo che slf4j-api non porti con sé l'implementazione. Con ciò intendo contrassegnare la dipendenza dell'implementazione come "test". PER ESEMPIO:

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

Questo è descritto in dettaglio nelle FAQ di SLF4j.

Per quanto riguarda gli altri due, IME, sono sempre compatibili con le versioni precedenti. Pertanto, se tra 5 anni avrò bisogno di usare la tua libreria ma stai usando una vecchia versione di quelle, posso semplicemente escludere le tue dipendenze e il nostro codice continuerà a funzionare. In altre parole, usando queste librerie specifiche non presenterai jar-hell per gli altri.

Se uso la tua libreria tramite Maven, non noterò se la tua libreria è gonfia o no. Dipenderò solo dal tuo e lo userò. Penso che sia più importante che il tuo codice funzioni correttamente piuttosto che avere un footprint più piccolo. Preferisco che usi commons-io invece di reinventare la ruota con un bug.

— Daniel Kaplan
fonte

Grazie per la risposta, penso che siamo ampiamente d'accordo sull'approccio che dovrei adottare. Giusto per correggere un bit - il modo in cui si dovrebbe includere slf4j in un progetto di libreria è semplicemente includere slf4j-apie nessun altro artefatto correlato, fornito o meno. Vedi slf4j.org/manual.html#projectDep .

— Duncan Jones,

Ricordo alcuni esercizi dannosi per il cervello (miliardi di excludesecondi) che dovevo fare quando particolari moduli nelle mie dipendenze non potevano "concordare" su una versione slf4j. Dalla tua risposta sembra che se i progettisti di moduli lo esponessero come provided, non ci sarebbero problemi del genere, giusto?

— moscerino del

@gnat Normalmente questo sarebbe risolto (almeno in Maven), dichiarando una versione preferita nel tuo POM. Maven prende la versione "più vicina" definita per un artefatto e l'immediata POM supera le dipendenze transitive. Forse questo è stato un cambiamento comportamentale durante una versione di Maven 2.x.

— Duncan Jones,

+1 per specificare slf4j come provided- molto discreto.

— Gary Rowe,

@DuncanJones grazie, probabilmente mi sono perso questo allora. La mia versione di Maven era 2.2 o 2.3, non riesco a ricordare quale (anche se ricordo sicuramente come mvn dependency:analyzestava portando versioni di merda fino all'esclusione :)

— moscerino

No.

"Bloat" è un mito. Indipendentemente dalla quantità di codice presente nella libreria, se parte di tale codice non viene mai utilizzato, non verrà eseguito il paging in - non avrà alcun impatto su prestazioni o footprint di memoria.

D'altra parte, se hai bisogno di quel pezzo in più di funzionalità hai due scelte. Puoi scriverlo tu stesso e dedicare molto tempo e fatica a risolvere i problemi che altri hanno già risolto in precedenza, oppure puoi scegliere di utilizzare la soluzione già esistente (ed è stata testata / debuggata / ecc.).

Questo ci lascia con dimensioni del download e ingombro dello spazio su disco e, a meno che tu non stia parlando di numeri sciocchi, nel 2013 sono due fattori che dovrebbero essere vicini alla fine dell'elenco delle cose di cui devi preoccuparti.

— Maximus Minimus
fonte