Google Guava vs. Apache Commons [zamknięte]

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

• Google Guava (dawniej „Kolekcje Google”)
• Kolekcje Apache Commons

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.

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.

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.

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.

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)

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.