Google Guava vs Apache Commons [ditutup]

212

Saya sedang mencari implementasi peta dua arah di Jawa, dan menemukan dua perpustakaan ini:

Google Guava (sebelumnya "Google Collections")
Koleksi Apache Commons

Keduanya gratis, memiliki implementasi peta dua arah yang saya cari (BidiMap di Apache, BiMap di Google), ukurannya hampir sama (Apache 493 kB, Google 499 kB) [ed .: tidak lagi benar!] Dan sepertinya dalam segala hal sangat mirip dengan saya.

Yang mana yang harus saya pilih, dan mengapa? Apakah ada beberapa alternatif lain yang setara (harus gratis dan memiliki setidaknya peta dua arah)? Saya sedang bekerja dengan Java SE terbaru, jadi tidak perlu membatasi secara artifisial ke Java 5 atau semacamnya.

— Joonas Pulakka
sumber

5

Tentunya Anda harus memberi kami kriteria untuk memilih perpustakaan? Lisensi, kinerja, dependensi tambahan, obat generik pendukung, ...

— SteveD

1

Google Collections tersedia di repo1.maven.org: repo1.maven.org/maven2/com/google/collections/…

— Joachim Sauer

Saya berdiri dikoreksi - Saya sedang mencari di com / googlecode

— kdgregory

185

Menurut pendapat saya, pilihan yang lebih baik adalah Guava (sebelumnya dikenal sebagai koleksi Google):

lebih modern (memiliki obat generik)
itu benar-benar mengikuti persyaratan API Koleksi
itu dipelihara secara aktif
CacheBuilder dan itu pendahulunya MapMaker luar biasa

Apache Commons Collections adalah pustaka yang bagus juga, tetapi telah lama gagal menyediakan versi yang diaktifkan secara generik (yang merupakan kelemahan utama untuk API koleksi menurut saya) dan umumnya tampaknya dalam pemeliharaan / jangan-lakukan -too-much-work-on-it mode _{Baru-baru ini Koleksi Commons telah mengambil beberapa uap lagi, tetapi memiliki beberapa penangkapan untuk dilakukan.}.

Jika ukuran unduhan / memori jejak / ukuran kode adalah masalah maka Apache Commons Collections mungkin menjadi kandidat yang lebih baik, karena itu adalah ketergantungan umum dari perpustakaan lain. Karena itu menggunakannya dalam kode Anda sendiri juga berpotensi dilakukan tanpa menambahkan dependensi tambahan. Sunting: "Keuntungan" khusus ini telah sebagian ditumbangkan sekarang, karena banyak perpustakaan baru benar-benar bergantung pada Guava dan bukan pada Koleksi Apache Commons.

— Joachim Sauer
sumber

3

Apa yang saya benar-benar heran: mengapa tidak ada pendapat lain? Haruskah aku berperan sebagai penasihat setan? Lagipula, Apache Commons Collections bukanlah perpustakaan yang buruk.

— Joachim Sauer

10

Karena Apache tidak memiliki obat generik, saya pikir sudah jelas yang mana dari dua ini adalah masa depan. Google adalah langkah logis berikutnya. Namun, ini perasaan yang aneh, bahwa itu dibangun oleh The Giant ... tetapi selama itu di bawah lisensi gratis, itu seharusnya tidak masalah walaupun itu dibangun oleh Microsoft. Saya kira.

— Joonas Pulakka

12

Pembaca harus sadar bahwa ini adalah jawaban yang sangat lama dan banyak yang berubah

— Roy Truelove

1

@RoyTruelove Tidak mengejutkan saya bahwa banyak yang telah berubah dan saya akan senang mendengar pendapat Anda saat ini mengenai masalah ini, atau mungkin tautan ke ulasan / perbandingan yang lebih baru. Saya suka filosofi "tidak dapat diubah secara default / hanya bisa diubah jika diperlukan" dan dimasukkannya obat generik ke dalam jambu biji, tetapi bahan-bahan yang saya baca mungkin semuanya bertanggal seperti yang Anda katakan, utas ini telah menjadi.

— joeA

2

@ testerjoe2 - Maaf, saya menulis komentar itu sejak lama dan terus terang tidak ingat alasannya. Kalau dipikir-pikir, itu benar-benar tidak membantu! Saya tidak menyadari bahwa libs tidak berubah sejak 2010, tetapi saya tahu bahwa libs terus digunakan secara intensif, jadi saya katakan seharusnya aman. Jika saya memulai dengan proyek baru hari ini, saya mungkin akan melihat lebih dekat lib koleksi Goldman Sach: github.com/goldmansachs/gs-collections . Ketika Anda salah satu perusahaan paling jahat di dunia, Anda harus memastikan bahwa Anda memiliki perpustakaan koleksi java kickass.

— Roy Truelove

72

Dari faq: FAQ Google Collections

Mengapa Google membuat semua ini, padahal Google bisa mencoba meningkatkan Koleksi Apache Commons?

Koleksi Apache Commons sangat jelas tidak memenuhi kebutuhan kita. Itu tidak menggunakan obat generik, yang merupakan masalah bagi kami karena kami benci untuk mendapatkan peringatan kompilasi dari kode kami. Itu juga telah dalam "pola penahanan" untuk waktu yang lama. Kita dapat melihat bahwa itu membutuhkan investasi yang cukup besar dari kita untuk memperbaikinya sampai kita senang menggunakannya, dan sementara itu, perpustakaan kita sendiri sudah tumbuh secara organik.

Perbedaan penting antara perpustakaan Apache dan kami adalah bahwa koleksi kami sangat setia mematuhi kontrak yang ditentukan oleh antarmuka JDK yang mereka terapkan. Jika Anda meninjau dokumentasi Apache, Anda akan menemukan banyak contoh pelanggaran. Mereka layak mendapatkan pujian karena menunjukkan hal ini dengan sangat jelas, tetapi tetap saja, menyimpang dari perilaku pengumpulan standar berisiko! Anda harus berhati-hati dengan koleksi apa yang Anda lakukan; bug selalu menunggu untuk terjadi.

Koleksi kami sepenuhnya dihasilkan dan tidak pernah melanggar kontrak mereka (dengan pengecualian terisolasi, di mana implementasi JDK telah menetapkan preseden yang kuat untuk pelanggaran yang dapat diterima). Ini berarti Anda dapat mengirimkan salah satu koleksi kami ke metode apa pun yang mengharapkan Koleksi dan merasa cukup yakin bahwa segala sesuatunya akan berfungsi sebagaimana mestinya.

— Davide Consonni
sumber

71

Hal terpenting yang saya temukan yang menjadikan Google Collections tempat untuk memulai:

Generik (Koleksi tanpa Generik - FTL)
Konsistensi dengan kerangka kerja Koleksi (Josh Bloch adalah pemain kunci dalam kerangka kerja ini)
Ketepatan. Orang-orang ini sangat terikat untuk memperbaiki masalah ini; mereka memiliki sesuatu seperti tes unit 25K, dan terikat untuk mendapatkan API yang tepat.

Berikut adalah video Youtube yang luar biasa dari ceramah yang diberikan oleh penulis utama dan ia melakukan pekerjaan yang baik untuk membahas apa yang perlu diketahui tentang perpustakaan ini.

— joeslice
sumber

7

+1 untuk tautan video

— Jesper

1

Bacaan hebat selanjutnya tentang Google Collections: javalobby.org/articles/google-collections (wawancara dengan pencipta utamanya). Cari pertanyaan "Apa yang unik dari pendekatan Anda? Apa bedanya dengan, misalnya, Koleksi Apache Commons?"

— Jonik

4

Apache Commons Collections Versi 4 menggunakan obat generik. commons.apache.org/proper/commons-collections/release_4_0.html

— Abdull

-7

Dua hal lain (saya harap saya tidak salah)

Lisensi Guava (nama baru untuk koleksi google) adalah Lisensi Apache 2.0, yang berarti: sama seperti untuk proyek Apache Commons
Saya tidak dapat menemukan kode sumber Guava dalam file untuk diunduh (sepertinya hanya akses git yang mungkin)

— Olivier Faucheux
sumber

19

Sumber? Maksud Anda guci yang bisa dilampirkan di Eclipse? Itu disini . BTW: Ada apa dengan git clone https://code.google.com/p/guava-libraries/dan git checkout v11.0.2?

— Xaerxess

-7

Satu hal buruk tentang Guava adalah bahwa Multimap tidak memperpanjang java.util.Map. Jika Anda memiliki metode Anda sendiri yang berfungsi pada Maps, mereka tidak akan berfungsi pada Guava Multimaps (antarmuka Apache MultiMap memperluas java.util.Map). Saya yakin ada beberapa alasan bagus mengapa memang seperti itu tetapi juga tidak nyaman.

— matt
sumber

16

Jika Anda ingin menggunakan Multimaplike Map, selalu ada asMap()tampilan.

— Xaerxess

22

Bagaimana Anda mengharapkan Multimap untuk mengimplementasikan java.util.Map? Multi-peta pada dasarnya berbeda dari peta.

— sleske

1

Multimap <K, V> extends Map <K, Collection <V>> .. Saya kira G punya alasan bagus untuk tidak menggunakan Map sebagai superinterface.

— matt

10

@ lucek: Jika Anda melihat melalui Javadoc Map, dengan pemahaman bahwa setiap referensi Vakan benar-benar menjadi Collection<V>, saya pikir Anda akan melihat dengan cepat mengapa itu bukan superinterface yang bagus untuk Multimap<K, V>.

— ruakh