Beide sind kostenlos, haben die bidirektionale Kartenimplementierung, nach der ich gesucht habe (BidiMap in Apache, BiMap in Google), sind erstaunlicherweise fast gleich groß (Apache 493 kB, Google 499 kB) [ed.: no longer true!] und scheinen mir in jeder Hinsicht ziemlich ähnlich zu sein.
Welche 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, also keine Notwendigkeit, mich künstlich auf Java 5 oder ähnliches zu beschränken.
Sie sollten uns doch bestimmt die Kriterien für die Auswahl der Bibliothek nennen? Lizenz, Leistung, zusätzliche Abhängigkeiten, unterstützende Generika, …
Apache Commons Collections ist ebenfalls eine gute Bibliothek, aber sie hat lange versagt, eine generische Version (eine Haupt meiner Meinung nach ein Nachteil für eine Sammlungs-API) und scheint sich im Allgemeinen in einem Wartungsmodus zu befinden/nicht zu viel daran zu arbeiten In letzter Zeit hat Commons Collections wieder etwas Fahrt aufgenommen, hat aber noch Nachholbedarf..
Wenn Downloadgröße/Speicherbedarf/Codegröße ein Problem darstellen, sind Apache Commons Collections möglicherweise ein besserer Kandidat, da dies eine häufige Abhängigkeit von anderen Bibliotheken ist. Daher könnte es möglicherweise auch in Ihrem eigenen Code verwendet werden, ohne zusätzliche Abhängigkeiten hinzuzufügen. Bearbeiten: Dieser besondere “Vorteil” wurde inzwischen teilweise untergraben, da viele neue Bibliotheken tatsächlich von Guava abhängen und nicht auf Apache Commons-Sammlungen.
Was ich mich wirklich frage: Warum gibt es keine anderen Meinungen? Soll ich den Devils Advocate spielen? Apache Commons Collections ist schließlich keine schlechte Bibliothek.
– Joachim Sauer
20. September 2009 um 9:53 Uhr
Da es dem Apache an Generika fehlt, ist es meiner Meinung nach offensichtlich, welcher von diesen beiden die Zukunft hat. Google ist der nächste logische Schritt nach vorne. Es ist jedoch ein seltsames Gefühl, dass es von The Giant gebaut wurde … aber solange es unter einer freien Lizenz steht, sollte es keine Rolle spielen, selbst wenn es von Microsoft gebaut wurde. Ich vermute.
– Joonas Pulakka
21. September 2009 um 10:26 Uhr
Die Leser sollten sich darüber im Klaren sein, dass dies eine sehr alte Antwort und vieles hat sich geändert
– Roy Truelove
21. November 2014 um 22:29 Uhr
@RoyTruelove Es überrascht mich nicht, dass sich viel geändert hat, und ich würde gerne Ihre aktuellen Gedanken zu diesem Thema oder vielleicht einen Link zu einer neueren Bewertung / einem neueren Vergleich hören. Ich mag die Philosophie “standardmäßig unveränderlich / nur bei Bedarf veränderbar” und die Einbeziehung von Generika in Guave, aber die Materialien, die ich gelesen habe, sind möglicherweise alle so alt wie Sie sagen, dass dieser Thread geworden ist.
– joeA
22. November 2014 um 22:01 Uhr
@testerjoe2 – Tut mir leid, ich habe diesen Kommentar vor langer Zeit geschrieben und kann mich ehrlich gesagt nicht mehr an den Grund dafür erinnern. Im Nachhinein war es ein ziemlich wenig hilfreich! Mir war nicht klar, dass sich die Bibliotheken seit 2010 nicht geändert haben, aber ich weiß, dass sie weiterhin stark genutzt werden, und daher würde ich sagen, dass sie sicher sein sollten. Wenn ich heute mit einem neuen Projekt beginnen würde, würde ich mir wahrscheinlich die Sammlungsbibliothek von Goldman Sach genau ansehen: github.com/goldmansachs/gs-collections. Wenn Sie eines der bösesten Unternehmen der Welt sind, sollten Sie wirklich sicherstellen, dass Sie eine erstklassige Java-Sammlungsbibliothek haben.
Warum hat Google das alles gebaut, wenn es stattdessen hätte versuchen können, die Apache Commons Collections zu verbessern?
Die Apache Commons Collections haben unsere Anforderungen ganz klar nicht erfüllt. Es verwendet keine Generika, was für uns ein Problem darstellt, da wir es hassen, Kompilierungswarnungen von unserem Code zu erhalten. Auch sie befindet sich seit langem in einer Warteschleife. Wir konnten sehen, dass es eine ziemlich große Investition von uns erfordern würde, es zu reparieren, bis wir es gerne verwenden würden, und in der Zwischenzeit wuchs unsere eigene Bibliothek bereits organisch.
Ein wichtiger Unterschied zwischen der Apache-Bibliothek und unserer besteht darin, dass sich unsere Sammlungen sehr genau an die Verträge halten, die von den von ihnen implementierten JDK-Schnittstellen angegeben werden. Wenn Sie die Apache-Dokumentation lesen, werden Sie unzählige Beispiele für Verstöße finden. Sie verdienen Anerkennung dafür, dass sie so deutlich darauf hinweisen, aber dennoch ist es riskant, vom standardmäßigen Sammelverhalten abzuweichen! Sie müssen vorsichtig sein, was Sie mit einer solchen Sammlung tun; Bugs warten immer nur darauf, passiert zu werden.
Unsere Sammlungen sind vollständig generiert und verletzen niemals ihre Verträge (mit vereinzelten Ausnahmen, bei denen JDK-Implementierungen einen starken Präzedenzfall für akzeptable Verstöße geschaffen haben). Das bedeutet, dass Sie eine unserer Sammlungen an jede Methode übergeben können, die eine Sammlung erwartet, und ziemlich sicher sein können, dass die Dinge genau so funktionieren, wie sie sollten.
joeslice
Die wichtigsten Dinge, die ich gefunden habe, die Google Collections zum Ausgangspunkt machen:
Generika (Sammlungen ohne Generika — FTL)
Konsistenz mit dem Collections-Framework (Josh Bloch war eine Schlüsselfigur in diesem Framework)
Richtigkeit. Diese Jungs sind verzweifelt daran interessiert, dieses Problem richtig zu machen; Sie haben ungefähr 25.000 Einheitentests und sind daran gebunden, die API genau richtig zu machen.
Hier ist eine tolle Youtube-Video eines Vortrags, den der Hauptautor gehalten hat und der es gut versteht, Wissenswertes über diese Bibliothek zu diskutieren.
Tolle weiterführende Lektüre zu Google Collections: javalobby.org/articles/google-collections (ein Interview mit den wichtigsten Schöpfern). Achten Sie auf die Frage „Was ist einzigartig an Ihrem Ansatz? Wie unterscheidet er sich beispielsweise von der Apache Commons Collection?“
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, was bedeutet: die gleiche wie für das Apache-Commons-Projekt
Ich kann den Quellcode von Guava nicht in einer Datei zum Herunterladen finden (scheinbar ist nur ein Git-Zugriff möglich)
Eine unangenehme Sache bei Guava ist, dass Multimap java.util.Map nicht erweitert. Wenn Sie Ihre eigenen Methoden haben, die auf Maps funktionieren, funktionieren sie nicht auf Guava Multimaps (die Apache MultiMap-Schnittstelle erweitert java.util.Map). Ich bin sicher, dass es einen guten Grund gibt, warum es so ist, aber es ist auch unbequem.
Wenn Sie verwenden möchten Multimap wie Mapes gibt immer asMap() Aussicht.
– Xaerxess
3. September 2012 um 8:55 Uhr
Wie soll eine Multimap java.util.Map implementieren? Eine Multi-Map unterscheidet sich grundlegend von einer Map.
– schleske
16. Oktober 2012 um 14:01 Uhr
Multimap erweitert Map>.. Ich vermute, dass G guten Grund hatte, Map nicht als Superinterface zu verwenden.
– matt
17. Oktober 2012 um 9:51 Uhr
@lucek: Wenn du das Javadoc durchsuchst Mapmit dem Verständnis, dass jeder Verweis auf V wird eigentlich ein Collection<V>ich denke, Sie werden ziemlich schnell sehen, warum es kein gutes Superinterface für ist Multimap<K, V>.
– ruach
6. November 2012 um 18:31 Uhr
Wenn Sie verwenden möchten Multimap wie Mapes gibt immer asMap() Aussicht.
– Xaerxess
3. September 2012 um 8:55 Uhr
Wie soll eine Multimap java.util.Map implementieren? Eine Multi-Map unterscheidet sich grundlegend von einer Map.
– schleske
16. Oktober 2012 um 14:01 Uhr
Multimap erweitert Map>.. Ich vermute, dass G guten Grund hatte, Map nicht als Superinterface zu verwenden.
– matt
17. Oktober 2012 um 9:51 Uhr
@lucek: Wenn du das Javadoc durchsuchst Mapmit dem Verständnis, dass jeder Verweis auf V wird eigentlich ein Collection<V>ich denke, Sie werden ziemlich schnell sehen, warum es kein gutes Superinterface für ist Multimap<K, V>.
– ruach
6. November 2012 um 18:31 Uhr
13553200cookie-checkGoogle Guave vs. Apache Commons [closed]yes
Sie sollten uns doch bestimmt die Kriterien für die Auswahl der Bibliothek nennen? Lizenz, Leistung, zusätzliche Abhängigkeiten, unterstützende Generika, …
– Steve D
18. September 2009 um 13:13 Uhr
Google Collections ist auf repo1.maven.org verfügbar: repo1.maven.org/maven2/com/google/collections/…
– Joachim Sauer
18. September 2009 um 13:21 Uhr
Ich stehe korrigiert – ich habe in com/googlecode gesucht
– kdgregory
18. September 2009 um 14:22 Uhr