Google Guava vs. Apache Commons [zamknięte]

212

Szukałem implementacji map dwukierunkowych w Javie i natknąłem się na te dwie biblioteki:

Oba są bezpłatne, mają implementację mapy dwukierunkowej, której szukałem (BidiMap w Apache, BiMap w Google), są niesamowicie prawie tego samego rozmiaru (Apache 493 kB, Google 499 kB) [wyd .: już nie prawda!] I wydają się pod każdym względem bardzo podobny do mnie.

Który powinienem wybrać i dlaczego? Czy istnieją inne równoważne alternatywy (muszą być bezpłatne i mieć przynajmniej mapę dwukierunkową)? Pracuję z najnowszą wersją Java SE, więc nie muszę sztucznie ograniczać się do Java 5 lub czegoś podobnego.

java collections apache-commons guava Joonas Pulakka
źródło
5
Z pewnością powinieneś podać nam kryteria wyboru biblioteki? Licencja, wydajność, dodatkowe zależności, obsługa generycznych, ...
SteveD
1
Kolekcje Google są dostępne na repo1.maven.org: repo1.maven.org/maven2/com/google/collections/…
Joachim Sauer
Stoję poprawiony - szukałem w com / googlecode
kdgregory,

Odpowiedzi:

185

Moim zdaniem lepszym wyborem jest Guava (wcześniej znana jako kolekcje Google):

  • jest bardziej nowoczesny (ma ogólne)
  • absolutnie spełnia wymagania interfejsu API kolekcji
  • jest aktywnie utrzymywany
  • CacheBuildera jego poprzednik MapMakerjest po prostu niesamowity

Kolekcje Apache Commons są również dobrą biblioteką, ale od dawna nie udostępnia ona wersji generycznej (co jest, moim zdaniem, poważną wadą interfejsu API kolekcji) i ogólnie wydaje się, że jest w utrzymaniu / nie robi Tryb -too-much-on-it Ostatnio Kolekcje Commons ponownie nabrały siły, ale ma jeszcze trochę do nadrobienia. .

Jeśli rozmiar pobierania / rozmiar pamięci / rozmiar kodu jest problemem, to kolekcje Apache Commons mogą być lepszym kandydatem, ponieważ jest to powszechna zależność innych bibliotek. Dlatego też użycie go we własnym kodzie może potencjalnie zostać wykonane bez dodawania jakichkolwiek dodatkowych zależności. Edycja: Ta szczególna „przewaga” została już częściowo osłabiona, ponieważ wiele nowych bibliotek faktycznie zależy od Guawy, a nie od zbiorów Apache Commons.

Joachim Sauer
źródło
3
Co naprawdę się zastanawiam: dlaczego nie ma innych opinii? Czy powinienem grać w adwokata diabłów? W końcu zbiory Apache Commons nie są złą biblioteką.
Joachim Sauer,
10
Ponieważ Apache nie ma generyków, myślę, że jest oczywiste, która z nich jest przyszłością. Google to kolejny logiczny krok naprzód. Dziwne jest jednak to, że jest zbudowany przez Giganta ... ale dopóki jest objęty bezpłatną licencją, nie powinno mieć znaczenia, nawet jeśli został zbudowany przez Microsoft. Zgaduję.
Joonas Pulakka
12
Czytelnicy powinni wiedzieć, że jest to bardzo stara odpowiedź i wiele się zmieniło
Roy Truelove
1
@RoyTruelove Nie dziwi mnie to, że wiele się zmieniło i chciałbym usłyszeć twoje bieżące przemyślenia na ten temat, a może link do nowszej recenzji / porównania. Podoba mi się filozofia „niezmienna domyślnie / zmienna tylko w razie potrzeby” i włączenie leków generycznych do guawy, ale materiały, które czytałem, mogły być datowane tak, jak mówisz, że ten wątek się stał.
joeA
2
@ testerjoe2 - Przepraszam, napisałem ten komentarz dawno temu i, szczerze mówiąc, nie pamiętam przyczyny tego. Z perspektywy czasu było to dość nieprzydatne! Nie zdawałem sobie sprawy, że biblioteki nie zmieniły się od 2010 roku, ale wiem, że nadal są intensywnie używane, więc powiedziałbym, że powinny być bezpieczne. Gdybym dzisiaj rozpoczął nowy projekt, prawdopodobnie przyjrzałbym się kolekcji Goldmana Sacha lib: github.com/goldmansachs/gs-collections . Kiedy jesteś jedną z najbardziej złych firm na świecie, naprawdę powinieneś upewnić się, że masz bibliotekę kolekcji kickass java.
Roy Truelove
72

Z najczęściej zadawanych pytań: Najczęściej zadawane pytania dotyczące kolekcji Google

Dlaczego Google to wszystko zbudował, skoro zamiast tego mógł ulepszyć kolekcje Apache Commons?

Kolekcje Apache Commons bardzo wyraźnie nie spełniały naszych potrzeb. Nie korzysta z generycznych, co jest dla nas problemem, ponieważ nie znosimy ostrzeżeń o kompilacji z naszego kodu. Od dłuższego czasu jest również w „schemacie utrzymywania”. Widzieliśmy, że naprawienie go będzie wymagało od nas sporej inwestycji, dopóki nie będziemy z niego zadowoleni, a tymczasem nasza biblioteka już się rozwijała organicznie.

Ważną różnicą między biblioteką Apache a naszą jest to, że nasze zbiory bardzo wiernie przestrzegają umów określonych przez implementowane przez nich interfejsy JDK. Jeśli przejrzysz dokumentację Apache, znajdziesz niezliczone przykłady naruszeń. Zasługują na uznanie za ich jednoznaczne wskazanie, jednak odejście od standardowych zachowań dotyczących zbiórki jest ryzykowne! Musisz uważać, co robisz z taką kolekcją; błędy zawsze czekają, aż się wydarzy.

Nasze kolekcje są w pełni generowane i nigdy nie naruszają ich umów (z pojedynczymi wyjątkami, w których implementacje JDK stanowią silny precedens dla dopuszczalnych naruszeń). Oznacza to, że możesz przekazać jedną z naszych kolekcji do dowolnej metody, która oczekuje kolekcji, i czuć się całkiem pewnie, że wszystko będzie działać dokładnie tak, jak powinno.

Davide Consonni
źródło
71

Najważniejsze rzeczy, które znalazłem, które sprawiają, że Kolekcje Google to miejsce, od którego możesz zacząć:

  • Generics (Kolekcje bez generics - FTL)
  • Spójność z ramami kolekcji (Josh Bloch był kluczowym graczem w tych ramach)
  • Poprawność Ci faceci są desperacko przywiązani do rozwiązania tego problemu; mają coś w rodzaju testów jednostkowych na poziomie 25 000 i są przywiązani do właściwego interfejsu API.

Oto świetny film na Youtube z wykładem, który został wygłoszony przez głównego autora, a on ma świetną robotę, dyskutując o tym, co warto wiedzieć o tej bibliotece.

joeslice
źródło
7
+1 za link do filmu
Jesper
1
Świetne dalsze czytanie na temat zbiorów Google: javalobby.org/articles/google-collections (wywiad z głównymi twórcami). Poszukaj pytania „Co wyróżnia twoje podejście? Czym różni się na przykład od kolekcji Apache Commons?”
Jonik
4
Kolekcje Apache Commons w wersji 4 korzystają z generycznych. commons.apache.org/proper/commons-collections/release_4_0.html
Abdull
-7

Dwie inne rzeczy (mam nadzieję, że się nie mylę)

  • Licencja Guava (nowa nazwa kolekcji Google) to Apache License 2.0, co oznacza: taka sama jak w przypadku projektu Apache Commons
  • Nie mogę znaleźć kodu źródłowego Guava w pliku do pobrania (wydaje się, że możliwy jest tylko dostęp do git)
Olivier Faucheux
źródło
19
Źródła? Masz na myśli słoik, który można dołączyć w Eclipse? To tutaj . BTW: Co jest nie tak z git clone https://code.google.com/p/guava-libraries/i git checkout v11.0.2?
Xaerxess,
-7

Jedną z nieprzyjemnych rzeczy w Guava jest to, że Multimap nie rozszerza java.util.Map. Jeśli masz własne metody działające na Mapach, nie będą one działać na Guava Multimaps (interfejs Apache MultiMap rozszerza java.util.Map). Jestem pewien, że istnieje jakiś dobry powód, dla którego tak jest, ale jest to również niewygodne.

matowy
źródło
16
Jeśli chcesz użyć Multimapjak Map, zawsze jest asMap()widok.
Xaerxess,
22
Jak możesz oczekiwać, że Multimap zaimplementuje java.util.Map? Wiele map różni się zasadniczo od mapy.
sleske
1
Multimapa <K, V> rozszerza mapę <K, kolekcja <V>> .. Podejrzewam, że G miał dobry powód, aby nie używać mapy jako superinterfejsu.
mat.
10
@lucek: Jeśli spojrzysz na Javadoc Map, mając na uwadze, że każde odniesienie Vbędzie w rzeczywistości Collection<V>, myślę, że szybko zrozumiesz, dlaczego nie jest to dobry superinterface Multimap<K, V>.
ruakh