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

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

• Google Guava (ранее "Коллекции Google")
• Коллекции Apache Commons

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

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

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

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

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

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

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

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

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

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

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

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

• Дженерики (Коллекции без Дженериков - FTL)
• Согласованность со структурой коллекций (Джош Блох был ключевым игроком в этой структуре)
• Корректность. Эти ребята отчаянно связаны с решением этой проблемы; у них есть что-то вроде 25K модульных тестов, и они привязаны к правильному API.

Вот отличное видео на Youtube о выступлении, которое дал основной автор, и он хорошо обсуждает, что стоит знать об этой библиотеке.

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

• Лицензия Guava (новое название для коллекций Google) - это лицензия Apache 2.0, то есть такая же, как и для проекта Apache Commons.
• Я не могу найти исходный код Guava в файле для загрузки (кажется, возможен только git-доступ)

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