Sollte meine kleine Softwarebibliothek die Verwendung anderer Bibliotheken vermeiden?

Ich habe gerade eine kleine Java-Bibliothek veröffentlicht, die nur wenige Klassen und Methoden bietet. Seit ich das Projekt mit Maven erstellt habe, habe ich sofort mehrere Bibliotheken von Drittanbietern verwendet, um meine Ziele zu erreichen, insbesondere:

commons-lang3 (für einige allgemeine Java-Sachen)
slf4j-api (zur Protokollierung)
commons-io (für ein kleines bisschen Datei-Zeug - ich glaube, ich lese eine Datei buchstäblich einmal)

Ich möchte nicht, dass meine Bibliothek in den Augen anderer aufgebläht erscheint. Sollte ich versuchen, mich nicht mehr auf diese Bibliotheken zu verlassen, um meinen Platzbedarf zu minimieren? Irgendwelche Ratschläge, welche Arten von Bibliotheken am besten zu vermeiden sind, wenn Sie erwägen, in Zukunft mehr zu verwenden?

java libraries maven

— Duncan Jones
quelle

Ein konkreter Teil Ihrer Frage scheint beantwortbar zu sein: Ihr Projekt plus konkrete Bibliotheken plus die Frage, ob es in Ordnung ist. Das Problem ist, dass Sie es zusammen mit dem allgemeinen Teil "sollte ... klein ... vermeiden" buchstabiert haben. Aus heutiger Sicht passt diese Frage nicht zu unserem Q & A-Format. Wir erwarten, dass die Antworten durch Fakten, Referenzen oder spezifisches Fachwissen gestützt werden, aber diese Frage wird wahrscheinlich Debatten, Argumente, Abstimmungen oder erweiterte Diskussionen hervorrufen. Wenn Sie der Meinung sind, dass diese Frage verbessert werden kann, lesen Sie die häufig gestellten Fragen ( FAQ) .

— gnat

@ Gnat Ich entschuldige mich. Als regelmäßiger Stack Overflow-Benutzer hatte ich angenommen, dass für Programmierer leicht subjektive Fragen akzeptabel sind. Gibt es eine Stack Exchange-Site, bei der solche Probleme in Ordnung sind? In der Zwischenzeit werde ich alle Unklarheiten aus meiner Frage entfernen.

— Duncan Jones

@gnat Diese Frage ist in Ordnung, auch in seiner ursprünglichen Form.

— Thomas Owens

@ThomasOwens mit allem Respekt, ich denke nicht so; für Originalfassung zwei Antworten mit entgegengesetzten Empfehlungen schnell dachte ich, sowohl angemessen gerechtfertigt: welcome Polling Spiel

— gnat

@gnat Nur zwei? Das ist gut. Lassen Sie sie posten und abstimmen. Zwei potenziell richtige Antworten mit Begründung und Begründung, die entgegengesetzt sind, machen die Frage nicht schlecht. Weder 3 noch 4 oder sogar 5. Es ist eine wohlgeformte Frage, mit der sich Entwickler von Problembibliotheken befassen müssen, und die Last wird dann auf die Antworten gelegt, um gute Antworten zu sein .

— Thomas Owens

Antworten:

Ich beantworte dies unter Berücksichtigung Ihrer spezifischen Situation. Ich würde sagen, dass es in Ordnung ist, diese Bibliotheken zu benutzen. Stellen Sie einfach sicher, dass Ihre slf4j-api die Implementierung nicht mitbringt. Damit meine ich, markieren Sie die Implementierungsabhängigkeit als "Test". Z.B:

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

Dies wird ausführlich in den SLF4j-FAQ beschrieben.

Die anderen beiden, IME, sind immer abwärtskompatibel. Daher kann ich, wenn ich in 5 Jahren Ihre Bibliothek verwenden muss, aber Sie eine alte Version davon verwenden, Ihre Abhängigkeiten einfach ausschließen und unser Code wird weiterhin funktionieren. Mit anderen Worten, wenn Sie diese speziellen Bibliotheken verwenden, werden Sie nicht jar-hell für andere einführen.

Wenn ich Ihre Bibliothek über maven benutze, merke ich nicht, ob Ihre Bibliothek aufgebläht ist oder nicht. Ich werde nur von dir abhängen und es verwenden. Ich denke, es ist wichtiger, dass Ihr Code korrekt funktioniert, als dass er einen geringeren Platzbedarf hat. Ich bevorzuge es, Commons-io zu verwenden, anstatt das Rad mit einem Fehler neu zu erfinden.

— Daniel Kaplan
quelle

Vielen Dank für die Antwort. Ich denke, wir sind uns im Großen und Ganzen einig, wie ich vorgehen soll. Nur um ein Bit zu korrigieren - die Art und Weise, wie man slf4j in ein Bibliotheksprojekt einbinden sollte, besteht darin, einfach slf4j-apiund ohne weitere verwandte Artefakte bereitzustellen oder auf andere Weise. Siehe slf4j.org/manual.html#projectDep .

— Duncan Jones

Ich erinnere mich an einige hirnschädigende Übungen (zig Millionen von excludes iirc), die ich machen musste, als bestimmte Module in meinen Abhängigkeiten sich nicht auf eine slf4j-Version "einigen" konnten. Ihrer Antwort providedzufolge sieht es so aus, als ob Modulentwickler dies offenlegen würden . Es gäbe keine derartigen Probleme, richtig?

— Mücke

@gnat Normalerweise würde dies behoben (zumindest in Maven), indem eine bevorzugte Version in Ihrem POM angegeben wird. Maven verwendet die "nächstgelegene" Version, die für ein Artefakt definiert ist, und der unmittelbare POM überwiegt die transitiven Abhängigkeiten. Möglicherweise war dies eine Verhaltensänderung während einer Maven 2.x-Version.

— Duncan Jones

+1 für die Angabe von slf4j als provided- sehr unauffällig.

— Gary Rowe

@DuncanJones danke, das habe ich damals wohl verpasst. Meine Maven-Version war 2.2 oder 2.3, ich kann mich nicht erinnern, welche (obwohl ich mich sicher erinnere, wie mvn dependency:analyzeMistversionen bis zum Ausschluss gebracht wurden :)

— Mücke

Nein.

"Aufblähen" ist ein Mythos. Unabhängig davon, wie viel Code sich in Ihrer Bibliothek befindet, wird ein Teil des Codes, der niemals verwendet wird, nicht weitergeleitet - dies hat keinerlei Auswirkungen auf die Leistung oder den Speicherbedarf.

Wenn Sie diese zusätzliche Funktionalität benötigen, haben Sie zwei Möglichkeiten. Sie können es entweder selbst schreiben und viel Zeit und Mühe aufwenden, um Probleme zu lösen, die andere bereits gelöst haben, oder Sie können die Lösung verwenden, die bereits vorhanden ist (und getestet / debuggt / etc).

Das lässt uns die Download-Größe und den Speicherplatzbedarf bestimmen, und es sei denn, Sie sprechen von dummen Zahlen. Im Jahr 2013 sind dies zwei Faktoren, die in der Liste der Dinge, über die Sie sich Sorgen machen müssen, am Ende stehen sollten.

— Maximus Minimus
quelle