Google Guava vs. Apache Commons [geschlossen]

StackOverflow https://stackoverflow.com/questions/1444437

Frage

Ich war auf der Suche nach einer bidirektionale Karte Implementierung in Java, und stolperte über diese beiden Bibliotheken:

Beide sind frei, haben die bidirektionale Karte Implementierung, die ich für (BidiMap in Apache, bimap in Google) suchen, sind erstaunlich fast die gleiche Größe (Apache 493 kB, Google 499 kB) [Hrsg .: nicht mehr wahr! ] und scheint in jeder Hinsicht ziemlich ähnlich wie mir.

Welche soll ich wählen, und warum? Gibt es einige andere gleichwertige Alternativen (muss die bidirektionale Karte zumindest frei sein und haben)? Ich bin mit dem neuesten Java SE arbeiten, so dass keine Notwendigkeit künstlich wie das zu Java 5 oder irgendetwas zu begrenzen.

War es hilfreich?

Lösung

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

  • es ist modernere (hat Generika)
  • folgt es unbedingt die Sammlungen API Anforderungen
  • es wird aktiv gepflegt
  • CacheBuilder und sein Vorgänger MapMaker sind einfach nur genial

Apache Commons Collections ist eine gute Bibliothek als gut, aber es hat es versäumt, lange eine Generika-fähige Version zur Verfügung zu stellen (das ist ein großer Nachteil für eine Sammlung API meiner Meinung nach) und scheint allgemein sein in einer Wartung / dO NOT-do-too-much-Arbeit-on-it-Modus vor kurzem hat Commons Kollektionen wieder etwas Dampf aufgenommen, aber es hat einige Nachholbedarf. .

Wenn Download-Größe / Speicher-Footprint / Code-Größe ist ein Problem dann Apache Commons Sammlungen könnte ein besserer Kandidat sein, da es sich um eine gemeinsame Abhängigkeit von anderen Bibliotheken ist. indem es in Ihrem eigenen Code damit auch potenziell ohne Zugabe von zusätzlichen Abhängigkeiten getan werden könnte. Edit:. Dieser besondere „Vorteil“ ist inzwischen teilweise unterlaufen worden, da viele neue Bibliotheken abhängen tatsächlich auf Guava und nicht auf Apache Commons Sammlungen

Andere Tipps

Die wichtigsten Dinge, die ich gefunden habe, dass Google Kollektionen den Ort machen zu starten:

  • Generics (Sammlungen ohne Generics - FTL)
  • Konsistenz mit Sammlungen Rahmen (Josh Bloch ein wichtiger Akteur in diesem Rahmen war)
  • Correctness. Diese Jungs sind verzweifelt gebunden dieses Problem richtig zu bekommen; sie haben so etwas wie 25K Unit-Tests und sind immer die API genau richtig gebunden.

Hier ist ein großer Youtube Video eine Rede, die von dem Hauptautor gegeben wurde und er macht einen guten Job zu diskutieren, was wert ist zu dieser Bibliothek zu kennen.

Von der FAQ: Google Sammlungen FAQ

  

Warum hat Google baut alles, wenn es versucht haben könnte, die Apache Commons Sammlungen statt zu verbessern?

     

Die Apache Commons Sammlungen sehr deutlich nicht erfüllen unsere Bedürfnisse. Es   verwendet keine Generika, was ein Problem für uns, da wir hassen zu bekommen   Kompilierung Warnungen aus unserem Code. Es hat sich auch in einem „Betrieb gewesen   Muster“für eine lange Zeit. Wir konnten sehen, dass es eine ziemlich erfordern würde   Großinvestition von uns, es zu beheben, bis wir zufrieden waren, es zu benutzen,   und in der Zwischenzeit unsere eigene Bibliothek bereits organisch wachsen.

     

Ein wichtiger Unterschied zwischen der Apache-Bibliothek und uns ist, dass   unsere Sammlungen sehr getreu an die angegebenen Verträge einhalten durch   die JDK-Schnittstellen sie implementieren. Wenn Sie den Apache überprüfen   Dokumentation, finden Sie unzählige Beispiele von Verletzungen zu finden. Sie   verdienen Kredit dieser für den Hinweis so deutlich aus, aber nach wie vor, abweichend   von Standard-Kollektion Verhalten ist riskant! Sie müssen vorsichtig sein, was   Sie tun mit einer solchen Sammlung; Fehler warten immer nur passieren.

     

Unsere Kollektionen voll generified und nie verletzen ihre Verträge   (Mit vereinzelten Ausnahmen, in denen JDK Implementierungen einen starken gesetzt haben   Präzedenzfall für akzeptable Verletzungen). Das heißt, Sie passieren kann eine von   unsere Sammlungen auf jedes Verfahren, das eine Sammlung und das Gefühl erwartet   ziemlich zuversichtlich, dass es funktioniert genau so, wie sie sollten.

Zwei weitere Dinge (ich hoffe, dass ich nicht falsch liege)

  • Die Lizenz von Guava (neuer Name für Google-Sammlungen) ist die Apache License 2.0, was bedeutet: die gleichen wie für Apache Commons Projekt
  • Ich kann den Quellcode von Guava in einer Datei zum Download finden (es scheint nur ein git-Zugang ist möglich)

Eine böse Sache über Guava ist, dass Multimap java.util.Map nicht verlängern. Wenn Sie Ihre eigenen Methoden, die auf Karten funktionieren sie funktionieren nicht auf Guava Multimaps (Apache MultiMap Schnittstelle java.util.Map erstreckt). Ich bin sicher, dass es einige gute Gründe, warum es so, wie es ist, aber es ist auch unbequem.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top