Google Guava vs. Apache Commons [закрито]

212

Наразі це запитання не підходить для нашого формату запитань. Ми очікуємо, що відповіді будуть підкріплені фактами, посиланнями або експертними знаннями, але це питання, ймовірно, вимагатиме дискусій, аргументів, опитувань чи розширеної дискусії. Якщо ви вважаєте, що це питання можна вдосконалити та, можливо, знову відкрити, відвідайте довідковий центр для ознайомлення .

Закрито 7 років тому .

Я шукав двонаправлену реалізацію карти на Java і натрапив на ці дві бібліотеки:

Google Guava (раніше "Колекції Google")
Колекції Apache Commons

Обидва є безкоштовними, мають двонаправлену реалізацію карти, яку я шукав (BidiMap в Apache, BiMap в Google), напрочуд майже однакового розміру (Apache 493 кБ, Google 499 кБ) [ред .: більше не вірно!] І здається у всіх відношеннях досить схожий на мене.

Яку вибрати, і чому? Чи існують інші еквівалентні альтернативи (повинні бути безкоштовними і мати принаймні двонаправлену карту)? Я працюю з останньою Java SE, тому не потрібно штучно обмежуватися Java 5 чи чим-небудь подібним.

— Йонас Пулака
джерело

5

Напевно, ви повинні дати нам критерії вибору бібліотеки? Ліцензія, продуктивність, додаткові залежності, що підтримують дженерики, ...

— SteveD

1

Колекції Google доступні на сайті repo1.maven.org: repo1.maven.org/maven2/com/google/collections/…

— Йоахім Зауер

Я виправлений - я шукав в com / googlecode

— kdgregory

185

На мій погляд, кращим вибором є Guava (раніше відомий як колекції Google):

це сучасніше (має дженерики)
він абсолютно відповідає вимогам API колекцій
це активно підтримується
CacheBuilderі його попередник MapMakerпросто чудовий

Колекції Apache Commons також є хорошою бібліотекою, але вона давно не змогла забезпечити версію з підтримкою generics (що, на мою думку, є головним недоліком API для колекцій) і, як правило, знаходиться в обслуговуванні / не робити Режим -oo-much-work-on-it _{Нещодавно Commons Collections знову взяв трохи пари, але це має щось наздогнати.}.

Якщо проблема завантаження / розмір пам'яті / розмір коду є проблемою, то Apache Commons Collection може бути кращим кандидатом, оскільки це звичайна залежність від інших бібліотек. Тому використання його у власному коді потенційно може бути здійснено без додавання додаткових залежностей. Редагувати: Ця особлива "перевага" до цього часу частково знищена, оскільки багато нових бібліотек насправді залежать від Гуави, а не від колекцій Apache Commons.

— Йоахім Зауер
джерело

3

Що мене справді цікавить: чому немає інших думок? Чи варто грати на захисника чортів? Зрештою колекції Apache Commons - це не погана бібліотека.

— Йоахім Зауер

10

Оскільки Apache бракує дженериків, я думаю, очевидно, що з цих двох - майбутнє. Google - це наступний логічний крок вперед. Це дивне відчуття, що його побудував The Giant ... але поки він знаходиться за вільною ліцензією, це не має значення, навіть якщо він був побудований Microsoft. Я вважаю.

— Joonas Pulakka

12

Читачі повинні знати, що це дуже стара відповідь і багато що змінилося

— Roy Truelove

1

@RoyTruelove Мене не дивує, що багато що змінилося, і я хотів би почути ваші поточні думки з цього приводу, чи, можливо, посилання на останній огляд / порівняння. Мені подобається філософія "незмінний за замовчуванням / змінний лише у разі потреби" та включення генерики в гуаву, але матеріали, які я читав, можуть бути датовані так, як ви кажете, що ця тема стала.

— joeA

2

@ testerjoe2 - Вибачте, я написав цей коментар давно і відверто не пам’ятаю причину цього. Заднім поглядом це було досить непомітно! Я не усвідомлював, що мочки не змінилися з 2010 року, але я знаю, що вони продовжують активно використовуватися, і тому я б сказав, що це повинно бути безпечним. Якби я розпочинав новий проект сьогодні, я, мабуть, уважно ознайомлюся зі збіркою колекції Goldman Sach: github.com/goldmansachs/gs-collections . Коли ви одна з найбільш злих компаній у світі, ви справді повинні переконатися, що у вас є бібліотека колекцій Java-колекції kickass.

— Roy Truelove

72

З питань: поширені запитання про колекції Google

Чому Google створив усе це, коли міг намагатися покращити колекції Apache Commons?

Колекції Apache Commons дуже очевидно не відповідали нашим потребам. Він не використовує дженерики, що є проблемою для нас, оскільки ми ненавидимо отримувати попередження про компіляцію з нашого коду. Він також давно перебуває у "схемі тримання". Ми могли бачити, що для того, щоб виправити це, нам знадобиться досить велика інвестиція, поки ми з радістю не використаємо її, а тим часом власна бібліотека вже органічно зростала.

Важливою відмінністю бібліотеки Apache від нашої є те, що наші колекції дуже сумлінно дотримуються договорів, визначених інтерфейсами JDK, які вони реалізують. Якщо ви переглянете документацію Apache, ви знайдете незліченну кількість прикладів порушень. Вони заслуговують на заслугу за те, що вони це чітко вказали, але все ж відхилятися від стандартної поведінки колекціонується ризиковано! Ви повинні бути обережними, що ви робите з такою колекцією; помилки завжди просто чекають, що станеться.

Наші колекції повністю узагальнені та ніколи не порушують їхніх контрактів (за окремими винятками, де впровадження JDK встановило вагомий прецедент для прийнятних порушень). Це означає, що ви можете передати одну з наших колекцій будь-якому методу, який очікує на колекцію, і ви впевнені, що все буде працювати саме так, як слід.

— Девід Консонні
джерело

71

Найважливіші речі, які я знайшов, що робить колекції Google місцем початку:

Generics (Колекції без дженериків - FTL)
Узгодженість з колекційними рамками (Джош Блок був ключовим гравцем у цій структурі)
Правильність. Ці хлопці відчайдушно прив’язані до вирішення цієї проблеми; у них є щось на зразок тестів на 25K одиниць, і вони пов'язані з тим, щоб отримати API правильно.

Ось чудове відео YouTube із розмови, яку виголосив головний автор, і він добре працює, обговорюючи, що варто знати про цю бібліотеку.

— joeslice
джерело

7

+1 за посилання на відео

— Jesper

1

Чудове подальше прочитання про колекції Google: javalobby.org/articles/google-collections (інтерв'ю з її основними творцями). Шукайте питання "Що є унікальним у вашому підході? Чим він відрізняється, наприклад, від колекції Apache Commons?"

— Джонік

4

Колекції Apache Commons Версія 4 використовують дженерики. commons.apache.org/proper/commons-collections/release_4_0.html

— Абдул

-7

Ще дві речі (сподіваюся, я не помиляюся)

Ліцензія Guava (нове ім'я для колекцій google) - ліцензія Apache 2.0, що означає: те саме, що і для проекту Apache Commons
Я не можу знайти вихідний код Guava у файлі для завантаження (здається, можливий лише git-доступ)

— Олів'є Фошо
джерело

19

Джерела? Ви маєте на увазі банку, яку можна прикріпити у Eclipse? Це тут . BTW: Що не так з git clone https://code.google.com/p/guava-libraries/і git checkout v11.0.2?

— Xaerxess

-7

Одна гарна річ у Guava - це те, що Multimap не поширює java.util.Map. Якщо у вас є власні методи роботи на Картах, вони не працюватимуть на Guava Multimaps (інтерфейс Apache MultiMap дійсно розширює java.util.Map). Я впевнений, що є якась вагома причина, чому це так, але це також незручно.

— матовий
джерело

16

Якщо ви хочете використовувати, Multimapяк Map, завжди є asMap()перегляд.

— Xaerxess

22

Як ви очікуєте, що Multimap реалізує java.util.Map? Мульти-карта принципово відрізняється від карти.

— sleske

1

Multimap <K, V> розширює Map <K, Collection <V>> .. Я підозрюю, що G мав всі підстави не використовувати Map як суперінтерфейс.

— мат

10

@lucek: Якщо ви подивитеся на Javadoc для Map, розуміючи, що кожна посилання на Vнасправді буде a Collection<V>, я думаю, ви досить швидко побачите, чому це не гарний суперінтерфейс Multimap<K, V>.

— ruakh