Google Guava ve Apache Commons'a karşı [kapalı]

212

Java'da çift yönlü bir harita uygulaması arıyordum ve bu iki kütüphaneyi tökezledim:

Google Guava (eski adıyla "Google Koleksiyonlar")
Apache Commons Koleksiyonları

Her ikisi de ücretsiz, aradığım iki yönlü harita uygulamasına sahip (Apache'de BidiMap, Google'da BiMap), neredeyse aynı boyutta (Apache 493 kB, Google 499 kB) [ed .: artık doğru değil!] Ve görünüyor her açıdan bana çok benziyor.

Hangisini seçmeliyim ve neden? Başka eşdeğer alternatifler var mı (ücretsiz olmalı ve en azından çift yönlü haritaya sahip olmalı)? En son Java SE ile çalışıyorum, bu yüzden yapay olarak Java 5 veya benzeri bir şeyle sınırlandırmaya gerek yok.

— Joonas Pulakka
kaynak

5

Elbette bize kütüphaneyi seçme kriterlerini vermelisiniz? Lisans, performans, ek bağımlılıklar, destekleyici jenerikler, ...

— SteveD

1

Google Koleksiyonlar repo1.maven.org adresinde bulunabilir: repo1.maven.org/maven2/com/google/collections/…

— Joachim Sauer

Düzeltilmiş durdum - com / googlecode

— Kdgregory

185

Kanımca daha iyi bir seçim Guava (eski adıyla Google koleksiyonları):

daha modern (jenerikler var)
Koleksiyonlar API gereksinimlerini kesinlikle karşılar
aktif olarak korunur
CacheBuilderve selefi MapMakersadece harika

Apache Commons Collections da iyi bir kütüphanedir, ancak uzun zamandır jenerik özellikli bir sürüm ( bence bir koleksiyon API'sı için büyük bir dezavantajdır) sağlamakta başarısız olmuştur ve genellikle bir bakım / yapmama gibi görünüyor -çok fazla-üzerinde-üzerinde-üzerinde modu _{Son zamanlarda Commons Koleksiyonlar tekrar biraz buhar aldı, ama yapmak için bazı yakalamak vardır.}.

İndirme boyutu / bellek alanı / kod boyutu bir sorunsa, Apache Commons Koleksiyonları daha iyi bir aday olabilir, çünkü diğer kütüphanelerin ortak bir bağımlılığıdır. Bu nedenle, kendi kodunuzda da kullanmak, herhangi bir ek bağımlılık eklemeden potansiyel olarak yapılabilir. Düzenleme: Birçok yeni kütüphane aslında Apache Commons Koleksiyonlar değil , Guava bağlıdır çünkü bu belirli "avantajı" kısmen yıkıldı .

— Joachim Sauer
kaynak

3

Gerçekten merak ediyorum: neden başka görüş yok? Şeytan avukatı mı oynamalıyım? Ne de olsa Apache Commons Koleksiyonları kötü bir kütüphane değil.

— Joachim Sauer

10

Apache jeneriklerden yoksun olduğundan, bu ikisinden hangisinin gelecek olduğu açıktır. Google, bir sonraki mantıklı adımdır. Yine de The Giant tarafından yapıldığı garip bir his ... ama ücretsiz bir lisans altında olduğu sürece Microsoft tarafından yapılmış olsa bile önemli olmamalı. Sanırım.

— Joonas Pulakka

12

Okuyucular bunun çok eski bir cevap olduğunu ve çok şey değiştiğini bilmelidir

— Roy Truelove

1

@RoyTruelove Çok şey değişti beni şaşırtmıyor ve konuyla ilgili mevcut düşüncelerinizi veya belki de daha yeni bir inceleme / karşılaştırmanın bağlantısını duymak isterim. "Gerekirse varsayılan / değişmez olarak değiştirilemez" felsefesini ve guava'ya jeneriklerin dahil edilmesini seviyorum, ancak okuduğum materyallerin hepsi bu konuya geldiğini söylediğiniz gibi tarihli olabilir.

— JoeA

2

@ testerjoe2 - Üzgünüm, uzun zaman önce bu yorumu yazdım ve açıkçası bunun nedenini hatırlamıyorum. Gez, oldukça yararsız biriydi! Kütüklerin 2010'dan bu yana değişmediğini fark etmedim, ancak yoğun olarak kullanılmaya devam ettiklerini biliyorum ve bu yüzden güvenli olması gerektiğini söyleyebilirim. Bugün yeni bir projeyle başlasaydım , muhtemelen Goldman Sach'ın toplama lib'ine yakından bakardım : github.com/goldmansachs/gs-collections . Dünyanın en kötü şirketlerinden biri olduğunuzda, gerçekten bir kickass java koleksiyonları kütüphanesine sahip olduğunuzdan emin olmalısınız.

— Roy Truelove

72

SSS'den: Google Koleksiyonlar SSS

Google neden bunun yerine Apache Commons Koleksiyonlarını geliştirmeye çalıştığında tüm bunları oluşturdu?

Apache Commons Koleksiyonları çok net bir şekilde ihtiyaçlarımızı karşılamadı. Kodumuzdan derleme uyarıları almaktan nefret ettiğimiz için bizim için bir sorun olan jenerik ilaç kullanmıyor. Aynı zamanda uzun zamandır bir “tutma modeli” içerisindedir. Kullanmaktan memnun olana kadar düzeltmek için bizden oldukça büyük bir yatırım gerektirdiğini görebiliyorduk ve bu arada kendi kütüphanemiz zaten organik olarak büyüyordu.

Apache kütüphanesi ve bizimkiler arasındaki önemli bir fark, koleksiyonlarımızın uyguladıkları JDK arayüzleri tarafından belirlenen sözleşmelere çok sadık bir şekilde uymalarıdır. Apache belgelerini incelerseniz, sayısız ihlal örneği bulacaksınız. Bunları bu kadar net bir şekilde belirttikleri için hak ediyorlar, ancak yine de standart toplama davranışından sapmak riskli! Böyle bir koleksiyonla ne yaptığınıza dikkat etmelisiniz; böcek her zaman sadece olmasını bekliyor.

Koleksiyonlarımız tamamen doğrulanmıştır ve sözleşmelerini asla ihlal etmemektedir (JDK uygulamalarının kabul edilebilir ihlaller için güçlü bir örnek oluşturduğu izole istisnalar hariç). Bu, koleksiyonlarımızdan birini bir Koleksiyon bekleyen herhangi bir yönteme aktarabileceğiniz ve her şeyin gerektiği gibi çalışacağından emin olabileceğiniz anlamına gelir.

— Davide Consonni
kaynak

71

Google Koleksiyonlarını başlayacak yer yapan bulduğum en önemli şeyler:

Jenerikler (Jeneriksiz Koleksiyonlar - FTL)
Koleksiyonlar çerçevesindeki tutarlılık (Josh Bloch bu çerçevede kilit bir oyuncuydu)
Doğruluk. Bu adamlar umutsuzca bu problemi düzeltmek için bağlılar; 25K birim testleri gibi bir şeye sahipler ve API'yi doğru yapmak için bağlılar.

İşte birincil yazar tarafından verilen bir konuşmanın harika bir Youtube videosu ve bu kütüphane hakkında bilinmeye değer olan şeyleri tartışmak için iyi bir iş çıkarıyor.

— joeslice
kaynak

7

Video bağlantısı için +1

— Jesper

1

Google Koleksiyonlar hakkında daha fazla okuma: javalobby.org/articles/google-collections (ana içerik oluşturucularıyla bir röportaj). "Yaklaşımınızla ilgili benzersiz olan nedir? Örneğin Apache Commons Koleksiyonu'ndan farkı nedir?"

— Jonik

4

Apache Commons Koleksiyonlar Sürüm 4 jenerikler kullanır. commons.apache.org/proper/commons-collections/release_4_0.html

— abdull

-7

İki şey daha (umarım yanlış değilim)

Guava lisansı (google koleksiyonları için yeni ad) Apache Lisans 2.0'dır, yani: Apache Commons projesiyle aynı
İndirmek için bir dosyada Guava kaynak kodunu bulamıyorum (sadece git-erişimi mümkün görünüyor)

— Olivier Faucheux
kaynak

19

Kaynaklar? Eclipse'e takılabilecek kavanoz mu demek istiyorsun? Burada . BTW: git clone https://code.google.com/p/guava-libraries/ve ile ilgili sorun nedir git checkout v11.0.2?

— Xaerxess

-7

Guava hakkında kötü bir şey, Multimap'in java.util.Map'i genişletmemesidir. Haritalar'da çalışan kendi yöntemleriniz varsa Guava Multimaps üzerinde çalışmazlar (Apache MultiMap arayüzü java.util.Map'i genişletir). Eminim bu şekilde olmasının iyi bir nedeni vardır ama aynı zamanda elverişsizdir.

— mat
kaynak

16

MultimapGibi kullanmak istiyorsanız Map, her zaman asMap()görünüm vardır.

— Xaerxess

22

Bir Multimap'in java.util.Map uygulamasını nasıl bekleyebilirsiniz? Çoklu harita temelde bir haritadan farklıdır.

— sleske

1

Multimap <K, V> Map <K, Collection <V>> 'yı genişletiyor.

— matt

10

@lucek: Eğer Mapher referansın Vaslında bir olacağı anlayışıyla Javadoc'a bakarsanız Collection<V>, bunun neden iyi bir süper arayüz olmadığını hemen anlayacağınızı düşünüyorum Multimap<K, V>.

— ruakh