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

Ответ 1

По моему мнению, лучший выбор Guava (ранее известный как коллекции Google):

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

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

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

Ответ 2

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

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

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

Ответ 3

Из faq: Коллекции Google FAO

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

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

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

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

Ответ 4

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

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

Ответ 5

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