우리는 현재 아파치 컬렉션, 문자열 유틸리티 등을 사용하고 있습니다. 아파치 기반 구현에서 전환해야하는지 결정해야합니다.
중요한 기준은 개발자의 사용 용이성입니다. 성능 / 메모리 사용량은 아직 우리에게 중요한 문제가 아닙니다. 이 시점에서 개발 속도가 핵심 기준입니다.
개발자의 삶이 구아바로 훨씬 쉬워 진 것에 대한 의견에 감사드립니다.
답변
첫째, javamonkey79가 설명했듯이 Google Guava와 Apache Commons는 유사한 기능을 공유하지만 둘 다 해당 제품에는없는 기능도 있습니다. 따라서 하나의 라이브러리로만 제한하는 것은 현명하지 않을 수 있습니다.
즉, 내가 선택해야한다면 Guava에 필요한 기능이없는 (드문) 경우를 위해 Apache Commons를 유지하면서 Guava를 사용하기로 선택했습니다. 이유를 설명해 드리겠습니다.
구아바는 더 “현대적”입니다.
Apache Commons는 정말 성숙한 라이브러리이지만 거의 10 년이 지났으며 Java 1.4를 대상으로합니다. Guava는 2007 년 에 오픈 소스로 Java 5를 대상으로했습니다. 따라서 Guava는 generics , varargs , enums 및 autoboxing 과 같은 Java 5 기능의 이점을 크게 얻었습니다 .
Guava 개발자에 따르면 제네릭은 Apache Commons를 개선하는 대신 새 라이브러리를 만들기로 선택한 이유 중 하나입니다 ( ‘Google이 Apache를 개선하려고 시도했을 때이 모든 것을 구축 한 이유는 무엇입니까?’ 라는 제목 아래 google-collections FAQ 참조). 대신 Commons Collections? “ ).
나는 그들에 동의한다 : 종종 비판을 받았지만 (수정이없고, 이전 버전과의 호환성으로 인해 제한됨), Java 제네릭은 Guava처럼 적절하게 사용될 때 여전히 매우 유용합니다. 생성되지 않은 컬렉션으로 작업하는 것보다 그만두고 싶습니다!
(Apache Commons 3.0 은 Java 1.5 이상을 대상으로합니다.)
구아바는 매우 잘 설계 / 문서화되어 있습니다.
이 코드는 API를 더 읽기 쉽고, 검색 가능하고, 성능이 뛰어나고, 안전하고, 스레드로부터 안전하게 만드는 모범 사례와 유용한 패턴으로 가득 차 있습니다.
Effective Java (굉장한 책 BTW) 를 읽은 후 코드에서 다음 패턴을 볼 수 있습니다.
- 공장 메소드 (예
ImmutableList.copyOf()) - 빌더 패턴 (
ImmutableList.builder(),Joiner,CharMatcher,Splitter,Ordering, …) - 불변성 (불변 모음,
CharMatcher,Joiner,Splitter, …) - 구현 숨기기 (
Predicates.xXx, …) - 상속 (
ForwardXXX컬렉션) 보다 구성을 선호 - 널 검사
- 열거 형 단일 패턴
- 직렬화 프록시
- 신중한 명명 규칙
이러한 디자인 선택으로 인한 이점을 몇 시간 동안 설명 할 수 있습니다 (원하는 경우 알려주세요). 문제는 이러한 패턴이 “쇼용”일뿐만 아니라 실제 가치가 있다는 것입니다. API는 사용하기 쉽고 배우기 쉬우 며 (문서화가 얼마나 잘되었는지 잊었습니까?), 더 효율적이며, 많은 클래스는 불변성으로 인해 더 간단하고 스레드로부터 안전합니다.
보너스 포인트로 코드를 보면 많은 것을 배울 수 있습니다. 🙂
구아바는 일관됩니다
Kevin Bourrillion (Guava의 수석 개발자)은 라이브러리 전체에서 높은 수준의 품질 / 일관성을 유지하는 데 큰 역할을합니다. 물론 그는 혼자가 아니며 많은 훌륭한 개발자 가 Guava에 기여했습니다 ( 현재 Google에서 일하는 Joshua Bloch 도 있습니다!).
구아바 뒤에 핵심 철학 및 디자인 선택 라이브러리에 걸쳐 일관성, 그리고 개발자 (안 JDK API를 과거의 실수에서 배운, 아주 좋은 (IMO) API 설계 원칙을 준수 들이 있지만, 실수).
구아바는 중량 대비 전력 비율이 높습니다.
Guava 디자이너는 API를 가장 유용한 기능으로 제한하여 너무 많은 기능을 추가하려는 유혹에 저항합니다. 그들은 일단 추가 된 기능을 제거하는 것이 매우 어렵다는 것을 알고 있으며, Joshua Bloch의 API 디자인에 대한 모토 인 “의심스러운 경우에는 제거하십시오”를 따릅니다 . 또한 @Beta 주석을 사용 하면 특정 API를 사용하지 않고도 일부 디자인 선택 을 테스트 할 수 있습니다 .
위에서 언급 한 디자인 선택은 매우 컴팩트 한 API를 허용합니다. 간단하게 볼 지도 작성기 는 “간단한”빌더 내부 포장 힘을 볼 수 있습니다. (더 간단하지만?) 다른 좋은 예는 CharMatcher , Splitter 및 Ordering 입니다.
구아바의 다양한 부분을 구성하는 것도 매우 쉽습니다. 예를 들어, 복잡한 함수 의 결과를 캐시하고 싶 습니까? 이 함수를 MapMaker 및 BINGO에 제공하면 스레드로부터 안전한 컴퓨팅 맵 / 캐시를 얻게됩니다. 맵 / 함수 입력을 특정 문자열로 제한해야합니까? 문제 없습니다 . CharMatcher 를 사용하여 부적절한 문자열을 거부 하는 ConstrainedMap 내부에 래핑합니다 .
구아바는 활발하게 개발 중입니다
Apache Commons의 개발이 Commons Lang 3.0에 대한 작업으로 가속화 된 것처럼 보이지만, Guava는 현재 더 많은 힘을 얻고있는 반면 Google은 내부 클래스의 더 많은 소스를 공개합니다.
구글은 내부적으로 크게 의존하고 있기 때문에 조만간 사라지지 않을 것이라고 생각합니다. 또한, 개방의 공통 라이브러리를 소싱하는 것은 더 쉽게 오픈 소스에 구글을 할 수 있습니다 기타 (대신에 의존 라이브러리 재 포장 Guice 현재처럼 그들을 않습니다 ).
결론
위의 모든 이유 때문에 Guava는 새 프로젝트를 시작할 때 가장 많이 찾는 라이브러리입니다. 그리고 저는 Google과이 환상적인 라이브러리를 만든 멋진 Guava 개발자에게 매우 감사합니다.
추신 : 당신은 또한 이 다른 질문 을 읽고 싶을 수도 있습니다.
PPS : Google 주식이 없습니다 (아직).
답변
저는 2010 년 8 월부터 r06 릴리스부터 구아바를 사용하고 있습니다. 기본적으로 개발할 그린 필드 자바 라이브러리가 있었기 때문에 J2SE API를위한 최고의 부속 라이브러리를 찾아 보았습니다. 전통적으로 우리는 Apache Commons 라이브러리를 사용했지만 거기에 무엇이 있는지보고 싶었고 Guava를 사용하기 시작했습니다.
장점
- Java 5.0 언어 구성. 라이브러리는 Bloch의 “Effective Java : 2nd Edition”(불변성, 빌더 패턴, 생성자 대신 팩토리, Generics 등)에서 대부분의 디자인 단서를 가져옵니다. 이는 코드를보다 단단하고 표현력있게 만듭니다.
- 기능적 프로그래밍 지원, 특히 최상위 수준의 Function 및 Predicate 인터페이스.
단점
- Apache Commons, 특히 commons-codec을 대체하기에 충분하지 않습니다.
- ‘구아바 요리 책’은 없습니다. 라이브러리는 미니멀하고 직교합니다. 따라서이를 최대한 활용하기위한 명확한 학습 곡선이 있습니다. 언급했듯이 Javadoc은 훌륭하지만 더 긴 소스 코드 사례 연구가 도움이 될 것입니다.
- Java 1.3 또는 1.4가 필요한 환경에 있다면 운이 좋지 않습니다.
나에게 Guava는 Java를 간결하고 표현력이 풍부한 스크립팅 언어에 더 가깝게 느끼게합니다.
답변
내 경험상 나는 그들이 서로 경쟁하거나 구아바가 아파치 라이브러리에서 향상된다는 것을 인식하지 못합니다. 오히려 구아바 는 아파치 라이브러리를 보완 합니다. 구아바에는 아파치에없는 클래스와 유틸리티가 있으며 그 반대의 경우도 마찬가지입니다.
따라서 저는 여러분이 그 자체로 전환해야한다는 것을 모릅니다. “올바른 작업에 적합한 도구 사용”이라고 말하겠습니다.
