В настоящее время мы используем коллекции apache, строковые утилиты и т. Д. Мне нужно решить, следует ли нам перейти от реализации основ apache.
Важный критерий - простота использования разработчиками. Производительность / использование памяти пока не является для нас важной проблемой. На этом этапе ключевым критерием является скорость разработки.
Буду признателен за мнения о том, как с гуавой жизнь разработчика стала значительно проще.
Ответы:
Во-первых, как объяснил 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коллекции)Я мог бы часами объяснять преимущества, которые дает такой выбор дизайна (скажите мне, если хотите). Дело в том, что эти шаблоны не только «для галочки», они имеют реальную ценность: 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.
Для меня Guava приближает Java к лаконичному и выразительному языку сценариев, и это здорово.
По моему опыту, я не замечаю, что они борются друг с другом или что гуава улучшает библиотеки apache. Скорее, гуава дополняет библиотеки apache. В гуаве есть классы и утилиты, которых нет в apache и наоборот.
Поэтому я не знаю, что вам нужно переключаться как таковое - я бы сказал: «Используйте правильный инструмент для правильной работы».
Files? Теперь в любое время, когда я хочу чтобы использовать JDK Files, я должен записать весь путь ...). Моему приложению требовалось много файловой утилиты, поэтому в этом случае я не смог избежать использования Apache.