Obecnie używamy kolekcji Apache, narzędzi łańcuchowych itp. Muszę zdecydować, czy powinniśmy przełączyć się z implementacji fundamentów Apache.
Ważnym kryterium jest łatwość obsługi programistów. Wydajność / zużycie pamięci nie jest dla nas jeszcze ważnym problemem. Na tym etapie kluczowym kryterium jest szybkość rozwoju.
Byłbym wdzięczny za opinie o tym, jak życie dewelopera stało się znacznie łatwiejsze dzięki guawie.
Odpowiedzi:
Po pierwsze, jak wyjaśnił javamonkey79 , podczas gdy Google Guava i Apache Commons mają podobne funkcje, oba mają również funkcje, których nie ma w ich odpowiedniku. Dlatego ograniczenie się tylko do jednej biblioteki może być nierozsądne.
Biorąc to pod uwagę, gdybym musiał wybrać, zdecydowałbym się na użycie Guavy, zachowując Apache Commons w (rzadkich) przypadkach, w których Guava nie ma potrzebnej funkcjonalności. Spróbuję wyjaśnić dlaczego.
Apache Commons to naprawdę dojrzała biblioteka, ale ma również prawie 10 lat i jest przeznaczona dla języka Java 1.4. Guawa był otwarty pozyskiwane w 2007 , skierowany Java 5, a tym samym guawa znacznie korzyści z Java 5 funkcji: rodzajowych , varargs , teksty stałe i autoboxing .
Według twórców Guava, generyczne są jednym z powodów, dla których zdecydowali się stworzyć nową bibliotekę zamiast ulepszać Apache Commons (patrz FAQ Google-collections pod tytułem „Dlaczego Google zbudował to wszystko, skoro mógł próbować ulepszyć Apache Kolekcje Commons? ” ).
Zgadzam się z nimi: chociaż często krytykowane (brak reifikacji, ograniczone ze względu na kompatybilność wsteczną), generyczne typy Java są nadal bardzo przydatne, gdy są odpowiednio używane, tak jak robi to Guava. Wolę rzucić palenie niż pracować z nieogenerowanymi kolekcjami!
(Zauważ, że Apache Commons 3.0, jest przeznaczony dla Java 1.5+)
Kod jest pełen najlepszych praktyk i przydatnych wzorców, dzięki którym API jest bardziej czytelne, wykrywalne, wydajne, bezpieczne i bezpieczne dla wątków ...
Po przeczytaniu Effective Java (tak przy okazji, niesamowita książka) widzę w kodzie te wzorce:
ImmutableList.copyOf())ImmutableList.builder(), Joiner, CharMatcher, Splitter, Ordering, ...)CharMatcher, Joiner, Splitter, ...)Predicates.xXx, ...)ForwardXXXkolekcje)Mógłbym godzinami wyjaśniać zalety wynikające z tych wyborów projektowych (powiedz mi, jeśli chcesz, żebym to zrobił). Rzecz w tym, że te wzorce są nie tylko „na pokaz”, mają realną wartość: API jest przyjemne w użyciu, łatwiejsze do nauczenia (czy zapomniałem powiedzieć, jak dobrze jest udokumentowane?), Wydajniejsze i wiele klas jest prostszych / bezpiecznych dla wątków ze względu na ich niezmienność.
Jako bonus, dużo się uczymy patrząc na kod :)
Kevin Bourrillion (główny programista Guava) wykonuje świetną robotę, utrzymując wysoki poziom jakości / spójności w całej bibliotece. Oczywiście nie jest sam, a wielu świetnych programistów przyczyniło się do powstania Guavy (nawet Joshua Bloch , który teraz pracuje w Google!).
Podstawowe filozofie i wybory projektowe stojące za Guava są spójne w całej bibliotece, a programiści stosują się do bardzo dobrych (IMO) zasad projektowania API, wyciągając wnioski z błędów popełnionych w przeszłości w API JDK (ale nie z ich błędów).
Projektanci Guava opierają się pokusie dodawania zbyt wielu funkcji, ograniczając API do najbardziej przydatnych. Wiedzą, że bardzo trudno jest usunąć dodaną funkcję i kierują się mottem Joshuy Blocha dotyczącym projektowania API: „W razie wątpliwości pomiń to” . Ponadto użycie adnotacji @Beta pozwala im przetestować niektóre wybory projektowe bez angażowania się w określone API .
Wspomniane powyżej wybory projektowe pozwalają na bardzo kompaktowe API. Wystarczy spojrzeć na Kreatora map, aby zobaczyć moc spakowaną w „prostym” konstruktorze. Inne dobre (choć prostsze?) Przykłady to CharMatcher , Splitter i Ordering .
Bardzo łatwo jest też komponować różne części guawy. Na przykład, powiedz, że chcesz zapisać w pamięci podręcznej wynik złożonej funkcji ? Prześlij tę funkcję do swojego Kreatora map i BINGO, otrzymałeś bezpieczną wątkowo mapę / pamięć podręczną. Chcesz ograniczyć dane wejściowe mapy / funkcji do określonych ciągów? Nie ma problemu, zawiń go w ConstrainedMap , używając CharMatchera do odrzucania niewłaściwych ciągów ...
Podczas gdy wydaje się, że rozwój Apache Commons przyspieszył wraz z pracami nad Commons Lang 3.0, Guava wydaje się w tej chwili nabierać większego tempa, podczas gdy Google otwiera źródła więcej ich wewnętrznych klas.
Ponieważ Google w dużym stopniu polega na nim wewnętrznie, nie sądzę, aby w najbliższym czasie zniknął. Co więcej, open source jego wspólnych bibliotek umożliwia Google łatwiejsze otwieranie źródeł innych bibliotek, które są od niego zależne (zamiast przepakowywać je, jak obecnie robi to Guice ).
Ze wszystkich powyższych powodów Guava jest moją biblioteką, do której wybieram się przy rozpoczynaniu nowego projektu. Jestem bardzo wdzięczny Google i niesamowitym programistom Guava, którzy stworzyli tę fantastyczną bibliotekę.
PS: możesz również przeczytać to inne pytanie SO
PPS: nie mam żadnych akcji Google (jeszcze)
Używam guawy od sierpnia 2010, począwszy od wydania r06. Zasadniczo miałem do opracowania bibliotekę java greenfield, więc rozejrzałem się za najlepszą biblioteką pomocniczą dla interfejsu API J2SE. Tradycyjnie korzystaliśmy z bibliotek Apache Commons, ale chciałem zobaczyć, co tam jest i zacząłem używać guawy.
Dla mnie guava sprawia, że Java jest bliższa zwięzłemu, ekspresyjnemu językowi skryptowemu i to świetnie.
Z mojego doświadczenia wynika, że nie dostrzegam, że walczą ze sobą lub że guawa poprawia libido apache. Raczej guawa uzupełnia biblioteki Apache. W guawie są klasy i narzędzia, których nie ma w apache i odwrotnie.
Dlatego nie wiem, czy trzeba się przełączać per se - powiedziałbym „użyj odpowiedniego narzędzia do odpowiedniej pracy”.
Files? Teraz, kiedy tylko chcę aby skorzystać z JDK Files, muszę wypisać całą ścieżkę ...). Moja aplikacja wymagała wielu narzędzi File, więc w tym przypadku nie mogłem uniknąć korzystania z Apache.