Şu anda apache koleksiyonları, string utils, vb. Kullanıyoruz. Apache Foundations uygulamasından geçiş yapıp yapmamaya karar vermem gerekiyor.
Önemli kriter geliştiricilerin kullanım kolaylığıdır. Performans / bellek kullanımı bizim için henüz önemli bir konu değil. Geliştirme hızı bu noktada kilit kriterdir.
Guava ile geliştiricinin hayatının nasıl önemli ölçüde kolaylaştırıldığına dair görüşlerimi takdir ediyorum.
Yanıtlar:
Öncelikle, javamonkey79'un açıkladığı gibi, Google Guava ve Apache Commons benzer özellikleri paylaşırken, her ikisi de muadillerinde bulunmayan işlevselliğe sahiptir. Bu nedenle, kendinizi yalnızca bir kitaplıkla sınırlamak akıllıca olmayabilir.
Bununla birlikte, eğer seçim yapmak zorunda kalsaydım, Guava'yı kullanmayı tercih ederdim, Guava'nın gerekli işlevselliğe sahip olmadığı (nadir) durumlarda Apache Commons'ı etrafta tutardım. Nedenini açıklamaya çalışayım.
Apache Commons gerçekten olgun bir kitaplıktır, ancak aynı zamanda neredeyse 10 yıllıktır ve Java 1.4'ü hedeflemektedir. Guava 2007'de açık kaynaklıydı , Java 5'i hedefliyordu ve bu nedenle Guava Java 5 özelliklerinden büyük ölçüde yararlanıyor: jenerikler , vararglar , numaralandırma ve otomatik kutulama .
Guava geliştiricilerine göre jenerik bunun yerine Apache Commons iyileştirilmesi için yeni bir kütüphane oluşturmak için seçti nedenlerinden biri (bkz olan google-koleksiyonları SSS başlığı altında, "Google neden inşa Bütün bunları yapan, bu Apache geliştirmeye çalıştık ne zaman Bunun yerine Commons Collections? " ).
Onlara katılıyorum: sık sık eleştirilse de (hiçbir şey ifade etmiyor, geriye dönük uyumluluk nedeniyle sınırlı), Java jenerikleri, Guava'nın yaptığı gibi uygun şekilde kullanıldığında hala çok kullanışlıdır. Jenerik olmayan koleksiyonlarla çalışmaktansa işi bırakmayı tercih ederim!
(Not Apache Commons 3.0, yani yapar 1.5+ hedef Java)
Kod, API'yi daha okunabilir, keşfedilebilir, performanslı, güvenli, iş parçacığı açısından güvenli hale getirmek için en iyi uygulamalar ve kullanışlı modellerle doludur ...
Etkili Java'yı (harika kitap BTW) okuduktan sonra, kodun her yerinde şu kalıpları görüyorum:
ImmutableList.copyOf())ImmutableList.builder(), Joiner, CharMatcher, Splitter, Ordering, ...)CharMatcher, Joiner, Splitter, ...)Predicates.xXx, ...)ForwardXXXkoleksiyonlar)Bu tasarım seçeneklerinin getirdiği avantajları açıklamak için saatlerce devam edebilirim (eğer istersen söyle). Mesele şu ki, bu modeller yalnızca "gösteri için" değil, gerçek bir değere sahipler: API'yi kullanmak bir zevk, öğrenmesi daha kolay (ne kadar iyi belgelendiğini söylemeyi unuttum mu?), Daha verimli ve birçok sınıf, değişmezlikleri nedeniyle daha basit / iş parçacığı açısından güvenlidir.
Bonus puan olarak, koda bakarak çok şey öğrenilir :)
Kevin Bourrillion (Guava'nın baş geliştiricisi), kitaplıkta yüksek düzeyde kalite / tutarlılık sağlayarak harika bir iş çıkarıyor. Elbette yalnız değil ve birçok harika geliştirici Guava'ya katkıda bulundu ( şu anda Google'da çalışan Joshua Bloch bile !).
Guava'nın arkasındaki temel felsefeler ve tasarım seçimleri, kitaplıkta tutarlıdır ve geliştiriciler, JDK API'lerinin geçmiş hatalarından ders alarak ( yine de hatalarından değil) çok iyi (IMO) API tasarım ilkelerine bağlı kalırlar .
Guava tasarımcıları, API'yi en kullanışlı olanlarla sınırlayarak çok fazla özellik eklemenin cazibesine direniyor. Eklenen bir özelliği kaldırmanın çok zor olduğunu biliyorlar ve Joshua Bloch'un API tasarımıyla ilgili sloganını takip ediyorlar : "Şüpheye düştüğünde, onu atla" . Ayrıca, @Beta açıklamasını kullanmak, belirli bir API taahhüt etmeden bazı tasarım seçeneklerini test etmelerine olanak tanır .
Yukarıda bahsedilen tasarım seçenekleri çok kompakt bir API'ye izin verir. "Basit" bir oluşturucu içinde paketlenmiş gücü görmek için Harita Oluşturucusuna bakın. Diğer iyi (daha basit de olsa?) Örnekler CharMatcher , Splitter ve Ordering'dir .
Guava'nın çeşitli kısımlarını oluşturmak da çok kolay. Örneğin, karmaşık bir sonucunu önbelleğe almak istediğini söylüyorsun fonksiyonu ? Bu işlevi MapMaker ve BINGO'nuza besleyin, iş parçacığı açısından güvenli bir bilgi işlem haritası / önbelleğiniz var. Harita / işlev girdilerini belirli Dizelerle sınırlamanız mı gerekiyor? Sorun değil, uygun olmayan Dizeleri reddetmek için bir CharMatcher kullanarak bir ConstrainedMap içine sarın ...
Apache Commons'ın gelişimi, Commons Lang 3.0 üzerindeki çalışmayla hızlanmış gibi görünse de, Guava şu anda daha fazla güç toplarken, Google kendi iç sınıflarının çoğunu kaynakları açıyor gibi görünüyor.
Google dahili olarak buna büyük ölçüde güvendiğinden, yakın zamanda ortadan kalkacağını düşünmüyorum. Ayrıca, ortak kitaplıklarının açık kaynak kullanımı, Google'ın ona bağlı olan diğer kitaplıkları daha kolay bir şekilde açmasına olanak tanır ( Guice'nin şu anda yaptığı gibi, onları yeniden paketlemek yerine ).
Yukarıdaki tüm nedenlerden ötürü, Guava, yeni bir projeye başlarken kitaplığımdır. Ve bu harika kitaplığı oluşturan Google'a ve harika Guava geliştiricilerine çok müteşekkirim.
Not: Bu diğer SO sorusunu da okumak isteyebilirsiniz
PPS: Herhangi bir Google hissem yok (henüz)
R06 sürümünden başlayarak Ağustos 2010'dan beri guava kullanıyorum. Temel olarak, geliştirmem gereken sıfırdan bir java kitaplığım vardı, bu yüzden J2SE API için en iyi yardımcı kitaplığı araştırdım. Geleneksel olarak Apache Commons kitaplıklarını kullanırdık, ama orada ne olduğunu görmek istedim ve Guava'yı kullanmaya başladım.
Bana göre Guava, Java'yı kısa ve anlamlı bir betik diline daha yakın hissettiriyor ve bu harika.
Tecrübelerime göre, onların birbirleriyle rekabet ettiklerini veya guava'nın apaçi libleri üzerinde geliştiğini algılamıyorum. Guava , apaçi kitaplarını tamamlar . Guava'da apache'de olmayan sınıflar ve yardımcı programlar vardır ve bunun tersi de geçerlidir.
Bu nedenle, kendi başınıza geçiş yapmanız gerektiğini bilmiyorum - "doğru iş için doğru aleti kullanın" derdim.
Files? Şimdi istediğim zaman JDK'yı kullanmak için Filestüm yolu yazmam gerekiyor ...). Uygulamamın çok sayıda Dosya yardımcı programına ihtiyacı vardı, bu yüzden bu durumda Apache'yi kullanmaktan kaçınamadım.