Google Guava против Apache Commons [закрыто]

212

Я искал реализацию двунаправленной карты в Java и наткнулся на эти две библиотеки:

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

Какой из них выбрать и почему? Существуют ли другие эквивалентные альтернативы (должны быть бесплатными и иметь хотя бы двунаправленную карту)? Я работаю с последней версией Java SE, поэтому нет необходимости искусственно ограничивать Java 5 или что-то подобное.

java collections apache-commons guava Joonas Pulakka
источник
5
Наверняка вы должны дать нам критерии выбора библиотеки? Лицензия, производительность, дополнительные зависимости, поддержка дженериков, ...
SteveD
1
Коллекции Google доступны на сайте repo1.maven.org: repo1.maven.org/maven2/com/google/collections/…
Иоахим Зауэр,
Я исправлен - я искал в com / googlecode
kdgregory

Ответы:

185

На мой взгляд, лучший выбор - это гуава (ранее известная как коллекция Google):

  • это более современно (имеет дженерики)
  • это абсолютно соответствует требованиям API Коллекций
  • это активно поддерживается
  • CacheBuilderи его предшественник MapMakerпросто потрясающий

Apache Commons Collections также является хорошей библиотекой, но она уже давно не может предоставить универсальную версию (которая, по моему мнению, является основным недостатком API для коллекций) и, как правило, находится в состоянии обслуживания / нереализации -too-much-work-on-it mode Недавно Commons Collections снова набрала обороты, но ей нужно наверстать упущенное. ,

Если размер загружаемого файла / объем памяти / размер кода является проблемой, то Apache Commons Collections может быть лучшим кандидатом, так как это общая зависимость других библиотек. Поэтому использование его в вашем собственном коде также может быть сделано без добавления каких-либо дополнительных зависимостей. Изменить: это конкретное «преимущество» к настоящему времени частично подорвано, так как многие новые библиотеки фактически зависят от Guava, а не от коллекций Apache Commons.

Йоахим Зауэр
источник
3
Что мне действительно интересно: почему нет других мнений? Должен ли я играть адвоката дьяволов? В конце концов, Apache Commons Collections - неплохая библиотека.
Иоахим Зауэр
10
Поскольку у Apache нет дженериков, я думаю, очевидно, какое из этих двух - будущее. Google - следующий логический шаг вперед. Однако это странное ощущение, что он создан The Giant ... но пока он находится под свободной лицензией, это не должно иметь значения, даже если он был построен Microsoft. Я думаю.
Joonas Pulakka
12
Читатели должны знать, что это очень старый ответ и многое изменилось
Рой Truelove
1
@RoyTruelove Меня не удивляет, что многое изменилось, и я хотел бы услышать ваши текущие мысли по этому вопросу, или, возможно, ссылку на более свежий обзор / сравнение. Мне нравится философия «неизменяемый по умолчанию / изменяемый, только если требуется» и включение дженериков в гуаву, но материалы, которые я читал, возможно, все датированы, как вы сказали, что эта тема стала.
JoeA
2
@ testerjoe2 - Извините, я давно написал этот комментарий и, честно говоря, не помню его причины. Оглядываясь назад, это было довольно бесполезно! Я не осознавал, что библиотеки не изменились с 2010 года, но я знаю, что они продолжают интенсивно использоваться, и поэтому я бы сказал, что они должны быть в безопасности. Если бы я начинал сегодня с новым проектом, я бы, наверное, внимательно посмотрел коллекцию Goldman Sach lib: github.com/goldmansachs/gs-collections . Когда вы одна из самых злых компаний в мире, вы действительно должны убедиться, что у вас есть отличная библиотека Java-коллекций.
Рой Truelove
72

Из часто задаваемых вопросов : Часто задаваемые вопросы о коллекциях Google

Почему Google построил все это, когда вместо этого мог попытаться улучшить Коллекции Apache Commons?

Коллекции Apache Commons очень явно не соответствовали нашим потребностям. Он не использует обобщений, что является проблемой для нас, так как мы ненавидим получать предупреждения компиляции из нашего кода. Это также было в "образце ожидания" в течение долгого времени. Мы могли видеть, что от нас потребуется довольно значительные инвестиции, чтобы исправить это, пока мы не будем рады его использовать, а тем временем наша собственная библиотека уже органически росла.

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

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

Давиде Консонни
источник
71

Самые важные вещи, которые я нашел, которые делают Коллекции Google местом для начала:

  • Дженерики (Коллекции без Дженериков - 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
Abdull
-7

Две другие вещи (надеюсь, я не ошибаюсь)

  • Лицензия Guava (новое название для коллекций Google) - это лицензия Apache 2.0, то есть такая же, как и для проекта Apache Commons.
  • Я не могу найти исходный код Guava в файле для загрузки (кажется, возможен только git-доступ)
Оливье Фошо
источник
19
Источники? Вы имеете в виду банку, которая может быть прикреплена в Eclipse? Это здесь . Кстати, что не так с git clone https://code.google.com/p/guava-libraries/и git checkout v11.0.2?
Xaerxess
-7

Одна неприятная вещь в Guava - Multimap не расширяет java.util.Map. Если у вас есть свои собственные методы, которые работают с картами, они не будут работать с мультикартами Guava (интерфейс Apache MultiMap действительно расширяет java.util.Map). Я уверен, что есть какая-то веская причина, почему это так, но это также неудобно.

матовый
источник
16
Если вы хотите использовать Multimapкак Map, всегда есть asMap()представление.
Xaerxess
22
Как вы ожидаете, что Multimap для реализации java.util.Map? Мультикарта принципиально отличается от карты.
слеске
1
Multimap <K, V> расширяет Map <K, Collection <V >> .. Я подозреваю, что у G была веская причина не использовать Map как суперинтерфейс.
матовый
10
@lucek: Если вы посмотрите на Javadoc Mapс пониманием того, что каждая ссылка на него на Vсамом деле будет Collection<V>, я думаю, вы довольно быстро поймете, почему это не хороший суперинтерфейс Multimap<K, V>.
Руах