Saat ini kami menggunakan koleksi apache, string utils, dll. Saya perlu memutuskan apakah kami harus beralih dari implementasi fondasi apache.
Kriteria penting adalah kemudahan penggunaan pengembang. Kinerja / penggunaan memori belum menjadi masalah penting bagi kami. Kecepatan perkembangan adalah kriteria utama saat ini.
Saya sangat menghargai pendapat tentang bagaimana kehidupan pengembang menjadi jauh lebih mudah dengan jambu biji.
Jawaban:
Pertama, seperti yang dijelaskan oleh javamonkey79 , meskipun Google Guava dan Apache Commons memiliki fitur yang serupa, keduanya juga memiliki fungsi yang tidak ada pada mitranya. Jadi, membatasi diri Anda hanya pada satu perpustakaan mungkin tidak bijaksana.
Karena itu, jika saya harus memilih, saya akan memilih untuk menggunakan Guava, menyimpan Apache Commons untuk kasus (jarang) di mana Guava tidak memiliki fungsionalitas yang diperlukan. Izinkan saya mencoba menjelaskan mengapa.
Apache Commons adalah pustaka yang sangat matang, tetapi juga berusia hampir 10 tahun, dan menargetkan Java 1.4. Guava bersumber terbuka pada tahun 2007 , menargetkan Java 5, dan karenanya Guava sangat diuntungkan dari fitur-fitur Java 5: generik , varargs , enum , dan autoboxing .
Menurut pengembang Guava, obat generik adalah salah satu alasan mereka memilih untuk membuat perpustakaan baru daripada meningkatkan Apache Commons (lihat FAQ google-collections , dengan judul "Mengapa Google membuat semua ini, padahal ia bisa mencoba meningkatkan Apache Koleksi Commons bukan? " ).
Saya setuju dengan mereka: walaupun sering dikritik (tidak ada reifikasi, terbatas karena kompatibilitas ke belakang), Java generik masih sangat berguna bila digunakan dengan tepat, seperti yang dilakukan Guava. Saya lebih suka berhenti daripada bekerja dengan koleksi yang tidak dibuat-buat!
(Perhatikan bahwa Apache Commons 3.0, tidak Target Java 1.5 +)
Kode ini penuh dengan praktik terbaik dan pola yang berguna untuk membuat API lebih mudah dibaca, ditemukan, berkinerja baik, aman, aman untuk thread ...
Setelah membaca Java Efektif (buku BTW yang mengagumkan), saya melihat pola-pola ini di mana-mana dalam kode:
ImmutableList.copyOf())ImmutableList.builder(), Joiner, CharMatcher, Splitter, Ordering, ...)CharMatcher, Joiner, Splitter, ...)Predicates.xXx, ...)ForwardXXXkoleksi)Saya bisa terus berjam-jam menjelaskan keuntungan yang dibawa oleh pilihan desain ini (beri tahu saya jika Anda menginginkan saya). Masalahnya, pola-pola ini tidak hanya "untuk pertunjukan", mereka memiliki nilai nyata: API menyenangkan untuk digunakan, lebih mudah dipelajari (apakah saya lupa mengatakan seberapa baik didokumentasikan?), Lebih efisien, dan banyak kelas yang lebih sederhana / aman untuk thread karena sifatnya yang tidak berubah.
Sebagai poin bonus, seseorang belajar banyak dengan melihat kode :)
Kevin Bourrillion (pengembang utama Guava) melakukan pekerjaan yang sangat baik dalam menjaga kualitas / konsistensi tingkat tinggi di seluruh perpustakaan. Dia tentu saja tidak sendiri, dan banyak developer hebat telah berkontribusi untuk Guava (bahkan Joshua Bloch , yang sekarang bekerja di Google!).
Filosofi inti dan pilihan desain di balik Guava konsisten di seluruh pustaka, dan pengembang mematuhi prinsip desain API yang sangat baik (IMO), setelah belajar dari kesalahan masa lalu JDK API (bukan kesalahan mereka ).
Para desainer Guava menahan godaan untuk menambahkan terlalu banyak fitur, membatasi API ke fitur yang paling berguna. Mereka tahu bahwa sangat sulit untuk menghapus fitur setelah ditambahkan, dan mengikuti moto Joshua Bloch tentang desain API: "Jika ragu, tinggalkan saja" . Selain itu, menggunakan anotasi @Beta memungkinkan mereka menguji beberapa pilihan desain tanpa harus menggunakan API tertentu .
Pilihan desain yang disebutkan di atas memungkinkan API yang sangat ringkas. Cukup lihat Pencipta Peta untuk melihat kekuatan yang dikemas di dalam pembuat "sederhana". Contoh bagus lainnya (meskipun lebih sederhana?) Adalah CharMatcher , Splitter , dan Ordering .
Juga sangat mudah untuk menyusun berbagai bagian Jambu Biji. Misalnya, Anda ingin menyimpan hasil dari fungsi kompleks ? Beri makan fungsi ini ke Pencipta Peta dan BINGO Anda, Anda mendapatkan peta / cache komputasi yang aman untuk thread. Perlu membatasi input peta / fungsi ke String tertentu? Tidak masalah, bungkuslah di dalam ConstrainedMap , menggunakan CharMatcher untuk menolak Strings yang tidak pantas ...
Sementara pengembangan Apache Commons tampaknya telah dipercepat dengan pengerjaan Commons Lang 3.0, Guava tampaknya mengambil lebih banyak tenaga saat ini, sementara Google membuka lebih banyak sumber kelas internal mereka.
Karena Google sangat bergantung padanya secara internal, saya tidak berpikir itu akan hilang dalam waktu dekat. Selain itu, sumber terbuka pustaka umumnya memungkinkan Google untuk lebih mudah membuka sumber pustaka lain yang bergantung padanya (daripada mengemasnya kembali, seperti yang dilakukan Guice saat ini ).
Untuk semua alasan di atas, Guava adalah pustaka pilihan saya saat memulai proyek baru. Dan saya sangat berterima kasih kepada Google dan para pengembang Guava yang luar biasa, yang membuat perpustakaan yang luar biasa ini.
PS: Anda mungkin juga ingin membaca pertanyaan SO lainnya ini
PPS: Saya belum memiliki saham Google (belum)
Saya telah menggunakan jambu biji sejak Agustus 2010, dimulai dengan rilis r06. Pada dasarnya, saya memiliki perpustakaan java greenfield untuk dikembangkan, jadi saya mencari-cari perpustakaan tambahan terbaik untuk J2SE API. Secara tradisional, kami menggunakan pustaka Apache Commons, tetapi saya ingin melihat apa yang ada di luar sana dan mulai menggunakan Guava.
Bagi saya, Guava membuat Java terasa lebih dekat dengan bahasa skrip yang singkat dan ekspresif, dan itu bagus.
Dalam pengalaman saya, saya tidak melihat bahwa mereka bersaing satu sama lain, atau bahwa jambu biji meningkat di apache libs. Sebaliknya, guava melengkapi libs apache. Ada kelas dan utilitas di jambu biji yang tidak ada di apache dan sebaliknya.
Oleh karena itu, saya tidak tahu bahwa Anda perlu beralih sendiri - saya akan mengatakan "gunakan alat yang tepat untuk pekerjaan yang tepat".
Files? Sekarang kapan saja saya mau untuk menggunakan JDK Files, saya harus menuliskan seluruh jalur ...). Aplikasi saya membutuhkan banyak utilitas File, jadi saya tidak dapat menghindari penggunaan Apache dalam kasus ini.