Google Guava vs. Apache Commons [geschlossen]

Ich suchte nach einer bidirektionalen Kartenimplementierung in Java und stieß auf diese beiden Bibliotheken:

• Google Guava (früher "Google Collections")
• Apache Commons-Sammlungen

Beide sind kostenlos, haben die von mir gesuchte bidirektionale Kartenimplementierung (BidiMap in Apache, BiMap in Google), sind erstaunlich fast gleich groß (Apache 493 kB, Google 499 kB) [Hrsg.: Nicht mehr wahr!] Und scheinen in jeder Hinsicht ziemlich ähnlich zu mir.

Welches soll ich wählen und warum? Gibt es andere gleichwertige Alternativen (muss kostenlos sein und mindestens die bidirektionale Karte haben)? Ich arbeite mit der neuesten Java SE, daher muss ich mich nicht künstlich auf Java 5 oder ähnliches beschränken.

Meiner Meinung nach ist Guava (früher bekannt als Google-Sammlungen) die bessere Wahl :

• es ist moderner (hat Generika)
• Es folgt absolut den Anforderungen der Sammlungs-API
• es wird aktiv gepflegt
• CacheBuilderund sein Vorgänger MapMakersind einfach fantastisch

Apache Commons Collections ist ebenfalls eine gute Bibliothek, hat jedoch lange Zeit keine generika-fähige Version bereitgestellt (was meiner Meinung nach ein großer Nachteil für eine Sammlungs-API ist) und scheint sich im Allgemeinen in einer Wartungs- / Nicht-Do-Funktion zu befinden -zu-viel-Arbeit-an-es-Modus _{In letzter Zeit hat Commons Collections wieder etwas} Fahrt aufgenommen _{, aber es gibt Nachholbedarf.} .

Wenn Downloadgröße / Speicherbedarf / Codegröße ein Problem darstellt, sind Apache Commons Collections möglicherweise ein besserer Kandidat, da dies eine häufige Abhängigkeit von anderen Bibliotheken ist. Daher kann die Verwendung in Ihrem eigenen Code möglicherweise auch ohne Hinzufügen zusätzlicher Abhängigkeiten erfolgen. Bearbeiten: Dieser besondere "Vorteil" wurde inzwischen teilweise untergraben, da viele neue Bibliotheken tatsächlich von Guava und nicht von Apache Commons-Sammlungen abhängen .

Aus der FAQ : Google Collections FAQ

Warum hat Google all dies erstellt, obwohl es stattdessen hätte versuchen können, die Apache Commons-Sammlungen zu verbessern?

Die Apache Commons-Sammlungen entsprachen eindeutig nicht unseren Anforderungen. Es werden keine Generika verwendet, was für uns ein Problem darstellt, da wir es hassen, Kompilierungswarnungen aus unserem Code zu erhalten. Es ist auch seit langer Zeit in einem "Warteschleifenmuster". Wir konnten sehen, dass es eine ziemlich große Investition von uns erfordern würde, um es zu reparieren, bis wir es gerne nutzen würden, und in der Zwischenzeit wuchs unsere eigene Bibliothek bereits organisch.

Ein wichtiger Unterschied zwischen der Apache-Bibliothek und unserer besteht darin, dass unsere Sammlungen die Verträge, die in den von ihnen implementierten JDK-Schnittstellen angegeben sind, sehr genau einhalten. Wenn Sie die Apache-Dokumentation lesen, finden Sie unzählige Beispiele für Verstöße. Sie verdienen Anerkennung dafür, dass sie so deutlich darauf hingewiesen haben, aber dennoch ist es riskant, vom Standard-Sammelverhalten abzuweichen! Sie müssen vorsichtig sein, was Sie mit einer solchen Sammlung machen; Bugs warten immer nur darauf, passiert zu werden.

Unsere Sammlungen werden vollständig generiert und verstoßen niemals gegen ihre Verträge (mit vereinzelten Ausnahmen, bei denen JDK-Implementierungen einen starken Präzedenzfall für akzeptable Verstöße darstellen). Dies bedeutet, dass Sie eine unserer Sammlungen an jede Methode übergeben können, die eine Sammlung erwartet, und sich ziemlich sicher sind, dass die Dinge genau so funktionieren, wie sie sollten.

Die wichtigsten Dinge, die ich gefunden habe, machen Google Collections zum Ausgangspunkt:

• Generika (Sammlungen ohne Generika - FTL)
• Übereinstimmung mit dem Sammlungsrahmen (Josh Bloch war ein Schlüsselspieler in diesem Rahmen)
• Richtigkeit. Diese Jungs sind verzweifelt daran gebunden, dieses Problem richtig zu machen. Sie haben so etwas wie 25K-Unit-Tests und sind daran gebunden, die API genau richtig zu machen.

Hier ist ein großartiges Youtube-Video eines Vortrags, der vom Hauptautor gehalten wurde, und er diskutiert gut, was es wert ist, über diese Bibliothek informiert zu werden.

Zwei andere Dinge (ich hoffe ich liege nicht falsch)

• Die Lizenz von Guava (neuer Name für Google-Sammlungen) ist die Apache-Lizenz 2.0, dh: dieselbe wie für das Apache Commons-Projekt
• Ich kann den Quellcode von Guava nicht in einer Datei zum Herunterladen finden (anscheinend ist nur ein Git-Zugriff möglich).

Eine böse Sache an Guava ist, dass Multimap java.util.Map nicht erweitert. Wenn Sie über eigene Methoden verfügen, die mit Maps funktionieren, funktionieren diese nicht mit Guava Multimaps (die Apache MultiMap-Oberfläche erweitert java.util.Map). Ich bin mir sicher, dass es einen guten Grund gibt, warum es so ist, aber es ist auch unpraktisch.