Во-первых, как объяснил javamonkey79 , хотя Google Guava и Apache Commons действительно имеют схожие функции, они также имеют функциональность, отсутствующую в их аналоге. Таким образом, ограничение только одной библиотекой может быть неразумным.
При этом, если бы мне пришлось выбирать, я бы предпочел использовать Guava, сохраняя Apache Commons для (редких) случаев, когда Guava не имеет необходимой функциональности. Позвольте мне попытаться объяснить почему.
Гуава более «современная»
Apache Commons - действительно зрелая библиотека, но ей почти 10 лет, и она нацелена на Java 1.4. Исходный код Guava был открыт в 2007 году , нацелен на Java 5, и поэтому Guava значительно выигрывает от функций Java 5: обобщений , varargs , перечислений и автобокса. .
По словам разработчиков Guava, дженерики - одна из причин, по которой они решили создать новую библиотеку вместо улучшения Apache Commons (см. FAQ по google-коллекциям под заголовком «Зачем Google создал все это, когда он мог попытаться улучшить Apache Коллекции Commons вместо этого? " ).
Я согласен с ними: несмотря на то, что они часто критикуются (без реификации, ограничены из-за обратной совместимости), дженерики Java все еще очень полезны при правильном использовании, как это делает Guava. Я лучше уйду, чем буду работать с необобщенными коллекциями!
(Обратите внимание , что Apache Commons 3.0, делает целевой Java 1.5+)
Гуава очень хорошо спроектирована / задокументирована
Код полон передовых практик и полезных шаблонов, чтобы сделать API более читаемым, доступным для обнаружения, производительным, безопасным, потокобезопасным ...
Прочитав Effective Java (отличная книга, кстати), я вижу эти шаблоны повсюду в коде:
- фабричные методы (такие как
ImmutableList.copyOf() )
- строитель шаблон (
ImmutableList.builder(), Joiner, CharMatcher, Splitter,Ordering , ...)
- неизменность (неизменяемые коллекции,
CharMatcher, Joiner,Splitter , ...)
- скрытие реализации (
Predicates.xXx, ...)
- предпочтение композиции перед наследованием (
ForwardXXXколлекции)
- нулевые чеки
- шаблон enum-singleton
- прокси сериализации
- хорошо продуманные соглашения об именах
Я мог бы часами объяснять преимущества, которые дает такой выбор дизайна (скажите мне, если хотите). Дело в том, что эти шаблоны не только «для галочки», они имеют реальную ценность: API приятно использовать, легче в освоении (я забыл сказать, насколько хорошо он документирован?), Более эффективен и многие классы проще / потокобезопасны из-за их неизменности.
В качестве бонуса можно многому научиться, глядя на код :)
Гуава последовательна
Кевин Бурриллион (ведущий разработчик Guava) отлично справляется с поддержанием высокого уровня качества / согласованности всей библиотеки. Он, конечно, не одинок, и много великих разработчиков внесли свой вклад в Guava (даже Джошуа Блох , который сейчас работает в Google!).
Основные философии и выбор дизайна, лежащие в основе Guava, единообразны во всей библиотеке, и разработчики придерживаются очень хороших (IMO) принципов проектирования API, извлекая уроки из прошлых ошибок API JDK (но не их ошибок).
Гуава имеет высокую удельную мощность.
Дизайнеры Guava сопротивляются соблазну добавить слишком много функций, ограничивая API наиболее полезными. Они знают, что очень сложно удалить добавленную функцию, и следуют девизу Джошуа Блоха по дизайну API: «Если есть сомнения, оставьте это» . Кроме того, использование аннотации @Beta позволяет им тестировать некоторые варианты дизайна без привязки к конкретному API .
Упомянутые выше варианты дизайна позволяют получить очень компактный API. Просто взгляните на MapMaker, чтобы увидеть всю мощь "простого" конструктора. Другими хорошими (хотя и более простыми?) Примерами являются CharMatcher , Splitter и Ordering .
Также очень легко составлять различные части гуавы. Например, вы хотите кэшировать результат сложной функции ? Загрузите эту функцию в свой MapMaker и BINGO, и вы получите поточно-ориентированную вычислительную карту / кеш. Необходимо ограничить ввод карты / функции определенными строками? Нет проблем, оберните его в ConstrainedMap , используя CharMatcher чтобы отклонить несоответствующие строки ...
Гуава находится в активной разработке
Хотя разработка Apache Commons, похоже, ускорилась с работой над Commons Lang 3.0, Guava, похоже, набирает обороты в настоящий момент, в то время как Google открывает исходные коды большего количества своих внутренних классов.
Поскольку Google сильно полагается на него внутри компании, я не думаю, что он исчезнет в ближайшее время. Кроме того, использование общих библиотек с открытым исходным кодом позволяет Google легче открывать другие библиотеки, зависящие от него (вместо того, чтобы переупаковывать их, как это делает сейчас Guice ).
Вывод
По всем вышеперечисленным причинам Guava - моя библиотека, которую я использую при запуске нового проекта. И я очень благодарен Google и замечательным разработчикам Guava, которые создали эту фантастическую библиотеку.
PS: вы также можете прочитать этот другой вопрос SO
PPS: У меня нет акций Google (пока)
Я использую гуаву с августа 2010 года, начиная с версии r06. По сути, мне нужно было разработать новую библиотеку java, поэтому я поискал лучшую вспомогательную библиотеку для J2SE API. Традиционно мы использовали библиотеки Apache Commons, но я хотел посмотреть, что там есть, и начал использовать Guava.
Pros
Cons
Для меня Guava приближает Java к лаконичному и выразительному языку сценариев, и это здорово.
источник
По моему опыту, я не замечаю, что они борются друг с другом или что гуава улучшает библиотеки apache. Скорее, гуава дополняет библиотеки apache. В гуаве есть классы и утилиты, которых нет в apache и наоборот.
Поэтому я не знаю, что вам нужно переключаться как таковое - я бы сказал: «Используйте правильный инструмент для правильной работы».
источник
Files? Теперь в любое время, когда я хочу чтобы использовать JDKFiles, я должен записать весь путь ...). Моему приложению требовалось много файловой утилиты, поэтому в этом случае я не смог избежать использования Apache.