В чем заключаются большие улучшения между библиотеками, эквивалентными guava и apache?

123

В настоящее время мы используем коллекции apache, строковые утилиты и т. Д. Мне нужно решить, следует ли нам перейти от реализации основ apache.

Важный критерий - простота использования разработчиками. Производительность / использование памяти пока не является для нас важной проблемой. На этом этапе ключевым критерием является скорость разработки.

Буду признателен за мнения о том, как с гуавой жизнь разработчика стала значительно проще.

похлопывание
источник

Ответы:

223

Во-первых, как объяснил 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 (пока)

Этьен Невё
источник
Спасибо! * краснеет * Я только что отредактировал свой ответ, чтобы подробнее рассказать об очень активной разработке Guava и подробнее рассказать о функциях Java 1.5.
Этьен Невё
1
Только что заметил, что Кевин Бурриллион говорит о Guava vs Apache Commons в этом разговоре: youtube.com/watch?v=9ni_KEkHfto#t=42m38s
Этьен Невё
Одно замечание: Guava довольно часто меняет свои API и отказывается от старых методов, поэтому наличие зависимостей от него может вызвать такие проблемы, как блокировки версий и несовместимость с другими сторонними библиотеками, которые используют Guava.
Архимед Траяно
24

Я использую гуаву с августа 2010 года, начиная с версии r06. По сути, мне нужно было разработать новую библиотеку java, поэтому я поискал лучшую вспомогательную библиотеку для J2SE API. Традиционно мы использовали библиотеки Apache Commons, но я хотел посмотреть, что там есть, и начал использовать Guava.

Pros

  1. Конструкции языка Java 5.0. Библиотека заимствует большую часть своих дизайнерских реплик из книги Блоха «Эффективная Java: 2-е издание»: неизменяемость, шаблон построителя, фабрики вместо конструкторов, обобщения и т. Д. Это делает ваш код более жестким и выразительным.
  2. Поддержка функционального программирования, в частности с интерфейсами верхнего уровня Function и Predicate.

Cons

  1. Это не достаточная замена Apache Commons, в частности commons-codec.
  2. Нет никакой «поваренной книги гуавы». Библиотека одновременно минималистична и ортогональна. Таким образом, есть определенная кривая обучения, чтобы использовать ее в полной мере. Как уже упоминалось, Javadoc превосходен, но были бы полезны некоторые более подробные примеры из исходного кода.
  3. Если вы находитесь в среде, требующей Java 1.3 или 1.4, вам не повезло.

Для меня Guava приближает Java к лаконичному и выразительному языку сценариев, и это здорово.

miniharryc
источник
16

По моему опыту, я не замечаю, что они борются друг с другом или что гуава улучшает библиотеки apache. Скорее, гуава дополняет библиотеки apache. В гуаве есть классы и утилиты, которых нет в apache и наоборот.

Поэтому я не знаю, что вам нужно переключаться как таковое - я бы сказал: «Используйте правильный инструмент для правильной работы».

javamonkey79
источник
1
Я пришел к такому выводу недавно, увидев, что Guava не имеет ничего даже близкого к тому, что предлагает Apache в FileNameUtils (да, есть совпадения, но FileNameUtils Apache имеет гораздо больше, чем файлы Guava. Кроме того, почему Google должен был использовать Files? Теперь в любое время, когда я хочу чтобы использовать JDK Files, я должен записать весь путь ...). Моему приложению требовалось много файловой утилиты, поэтому в этом случае я не смог избежать использования Apache.
Дон Чидл