Google Guava vs. Apache Commons [ปิด]

212

ฉันกำลังมองหาการใช้งานแผนที่สองทิศทางใน Java และสะดุดกับทั้งสองห้องสมุด:

ทั้งสองฟรีใช้งานแผนที่สองทิศทางที่ฉันกำลังมองหา (BidiMap ใน Apache, BiMap ใน Google), มีขนาดเกือบจะน่าอัศจรรย์ (Apache 493 kB, Google 499 kB) [ed. ไม่จริงอีกต่อไป!] และดูเหมือน ในทุก ๆ ด้านคล้ายกับฉัน

ฉันควรเลือกอันไหนและเพราะอะไร มีทางเลือกอื่นที่เทียบเท่า (ต้องฟรีและมีแผนที่สองทิศทางเป็นอย่างน้อย)? ฉันกำลังทำงานกับ Java SE ล่าสุดดังนั้นจึงไม่จำเป็นต้อง จำกัด Java 5 หรืออะไรทำนองนั้น

java  collections  apache-commons  guava 
— Joonas Pulakka
แหล่งที่มา
5
แน่นอนคุณควรให้เกณฑ์เราในการเลือกห้องสมุดหรือไม่ ใบอนุญาต, การทำงาน, การอ้างอิงเพิ่มเติมการสนับสนุนยาชื่อสามัญ ...
— SteveD
1
Google Collections มีให้ที่ repo1.maven.org: repo1.maven.org/maven2/com/google/collections/…
— Joachim Sauer
ฉันยืนแก้ไข - ฉันดูใน com / googlecode
— kdgregory

คำตอบ:

185

ในความคิดของฉันตัวเลือกที่ดีกว่าคือGuava (เดิมชื่อคอลเล็กชัน Google):

  • มันทันสมัยกว่า (มี generics)
  • มันเป็นไปตามข้อกำหนด API ของ Collections
  • มันบำรุงรักษาอย่างแข็งขัน
  • CacheBuilderและรุ่นก่อนMapMakerนั้นยอดเยี่ยมมาก

Apache Commons Collections เป็นห้องสมุดที่ดีเช่นกัน แต่ล้มเหลวในการให้บริการเวอร์ชันทั่วไป (ซึ่งเป็นข้อเสียเปรียบที่สำคัญสำหรับ API คอลเล็กชันในความคิดของฉัน) และโดยทั่วไปดูเหมือนว่าอยู่ในการบำรุงรักษา / ไม่ต้องทำ -too-very-work-on-it โหมดเมื่อไม่นานมานี้คอมมอนส์คอลเล็กชั่น Commons ได้หยิบไอน้ำออกมาอีกครั้ง แต่ก็มีบางอย่างที่ต้องทำ .

หากขนาดการดาวน์โหลด / หน่วยความจำรอยเท้า / ขนาดรหัสเป็นปัญหาแล้ว Apache Commons Collections อาจเป็นตัวเลือกที่ดีกว่าเนื่องจากเป็นการพึ่งพาทั่วไปของไลบรารีอื่น ๆ ดังนั้นการใช้มันในโค้ดของคุณเองก็สามารถทำได้โดยไม่ต้องเพิ่มการพึ่งพาเพิ่มเติมใด ๆ แก้ไข: ตอนนี้ "ความได้เปรียบ" โดยเฉพาะบางส่วนถูกทำลายเนื่องจากห้องสมุดใหม่จำนวนมากขึ้นอยู่กับ Guava และไม่ใช่ใน Apache Commons Collections

— Joachim Sauer
แหล่งที่มา
3
สิ่งที่ฉันสงสัยจริงๆ: ทำไมไม่มีความคิดเห็นอื่น ๆ ฉันควรจะเล่นเป็นผู้สนับสนุนปีศาจหรือไม่ Apache Commons Collections ไม่ใช่ห้องสมุดที่ไม่ดีเลย
— Joachim Sauer
10
ตั้งแต่ Apache ขาด generics ฉันคิดว่ามันชัดเจนว่าสองคนนี้คืออนาคต Google เป็นขั้นตอนต่อไปที่เป็นตรรกะ มันเป็นความรู้สึกแปลก ๆ ที่สร้างโดย The Giant ... แต่ตราบใดที่มันอยู่ภายใต้ใบอนุญาตฟรีมันก็ไม่สำคัญว่ามันจะถูกสร้างโดย Microsoft ฉันคิดว่า.
— Joonas Pulakka
12
ผู้อ่านควรตระหนักว่านี่เป็นคำตอบที่เก่ามากและมีการเปลี่ยนแปลงมากมาย
— Roy Truelove
1
@RoyTruelove ไม่แปลกใจเลยที่มีการเปลี่ยนแปลงมากมายและฉันชอบที่จะได้ยินความคิดปัจจุบันของคุณเกี่ยวกับเรื่องนี้หรืออาจจะเป็นลิงค์ไปสู่การรีวิว / การเปรียบเทียบล่าสุด ฉันชอบปรัชญา "ไม่เปลี่ยนรูปโดยค่าเริ่มต้น / ไม่แน่นอนถ้าจำเป็น" และการรวมของ generics ในฝรั่งเศษ แต่วัสดุที่ฉันได้อ่านมาทั้งหมดอาจจะล้าสมัยเหมือนที่คุณพูดในหัวข้อนี้
— joeA
2
@ testerjoe2 - ขออภัยฉันเขียนความคิดเห็นนั้นนานแล้วและตรงไปตรงมาจำไม่ได้ว่าเหตุผลสำหรับมัน ในการเข้าใจถึงปัญหามันเป็นคนที่ไม่ค่อยช่วยเหลือ! ฉันไม่ได้ตระหนักว่า libs นั้นไม่ได้เปลี่ยนไปตั้งแต่ปี 2010 แต่ฉันรู้ว่ามันยังคงถูกใช้อย่างหนักและดังนั้นฉันจึงบอกว่าควรจะปลอดภัย ถ้าผมได้เริ่มต้น w / โครงการใหม่ในวันนี้ผมอาจจะมีลักษณะใกล้ที่ Goldman Sach ของคอลเลกชัน lib: github.com/goldmansachs/gs-collections เมื่อคุณเป็นหนึ่งใน บริษัท ที่ชั่วร้ายที่สุดในโลกคุณควรตรวจสอบให้แน่ใจว่าคุณมีห้องสมุดคอลเลกชัน kickass java
— Roy Truelove
72

จากคำถามที่พบบ่อย : คำถามที่พบบ่อยของ Google คอลเล็กชัน

เหตุใด Google จึงสร้างสิ่งนี้ทั้งหมดเมื่อสามารถพยายามปรับปรุง Apache Commons Collections แทนได้

คอลเลกชัน Apache Commons ชัดเจนมากไม่ตรงกับความต้องการของเรา มันไม่ได้ใช้ยาชื่อสามัญซึ่งเป็นปัญหาสำหรับเราเนื่องจากเราเกลียดการรับคำเตือนการรวบรวมจากรหัสของเรา มันยังอยู่ใน "รูปแบบการถือครอง" เป็นเวลานาน เราจะเห็นว่ามันจะต้องมีการลงทุนที่สำคัญจากเราในการแก้ไขมันจนกว่าเราจะมีความสุขที่จะใช้มันและในขณะเดียวกันห้องสมุดของเราเองก็เติบโตขึ้นตามธรรมชาติ

ข้อแตกต่างที่สำคัญระหว่างห้องสมุด Apache กับเราคือคอลเลกชันของเราเป็นไปตามสัญญาที่ระบุไว้โดยส่วนต่อประสาน JDK ที่พวกเขาใช้อย่างซื่อสัตย์ หากคุณตรวจสอบเอกสาร Apache คุณจะพบตัวอย่างการละเมิดนับไม่ถ้วน พวกเขาสมควรได้รับเครดิตสำหรับการชี้ให้เห็นอย่างชัดเจน แต่ถึงกระนั้นการเบี่ยงเบนจากพฤติกรรมการเก็บแบบมาตรฐานก็เสี่ยง คุณต้องระวังสิ่งที่คุณทำกับคอลเลกชันดังกล่าว ข้อบกพร่องมักจะรอที่จะเกิดขึ้น

คอลเลกชันของเรานั้นได้รับการสร้างขึ้นอย่างสมบูรณ์และไม่ละเมิดสัญญาของพวกเขา (มีข้อยกเว้นบางประการที่การดำเนินการของ JDK ได้สร้างบรรทัดฐานที่แข็งแกร่งสำหรับการละเมิดที่ยอมรับได้) ซึ่งหมายความว่าคุณสามารถส่งผ่านหนึ่งในคอลเลกชันของเราไปยังวิธีการใด ๆ ที่คาดว่าจะมีการสะสมและรู้สึกค่อนข้างมั่นใจว่าสิ่งต่าง ๆ จะได้ผลตามที่ควร

— Davide Consonni
แหล่งที่มา
71

สิ่งสำคัญที่สุดที่ฉันได้พบซึ่งทำให้ Google คอลเลคชันเป็นสถานที่เริ่มต้น:

  • Generics (คอลเลกชันที่ไม่มี Generics - FTL)
  • ความสอดคล้องกับกรอบงาน Collections (Josh Bloch เป็นผู้เล่นหลักในกรอบงานนี้)
  • ความถูกต้อง พวกเหล่านี้ผูกติดอยู่กับการทำให้ปัญหานี้ถูกต้อง พวกเขามีบางอย่างเช่นการทดสอบหน่วย 25K และเชื่อมโยงกับการรับ API ที่ถูกต้อง

นี่คือวิดีโอ Youtubeที่ยอดเยี่ยมของการพูดคุยที่ได้รับจากผู้เขียนหลักและเขาทำงานได้ดีในการพูดคุยเกี่ยวกับสิ่งที่ควรรู้เกี่ยวกับห้องสมุดนี้

— joeslice
แหล่งที่มา
7
+1 สำหรับลิงก์วิดีโอ
— Jesper
1
อ่านเพิ่มเติมเกี่ยวกับ Google Collections เพิ่มเติมได้ที่: javalobby.org/articles/google-collections (สัมภาษณ์กับผู้สร้างหลัก) มองหาคำถาม "สิ่งที่เป็นเอกลักษณ์เกี่ยวกับวิธีการของคุณหรือไม่ตัวอย่างเช่น Apache Commons Collection แตกต่างกันอย่างไร"
— Jonik
4
Apache Commons Collections เวอร์ชัน 4 ใช้ข้อมูลทั่วไป commons.apache.org/proper/commons-collections/release_4_0.html
— Abdull
-7

อีกสองสิ่ง (ฉันหวังว่าฉันจะไม่ผิด)

  • ใบอนุญาตของ Guava (ชื่อใหม่สำหรับคอลเลกชัน google) คือ Apache License 2.0, ความหมาย: ชื่อเดียวกับโครงการ Apache Commons
  • ฉันไม่พบซอร์สโค้ดของ Guava ในไฟล์ที่จะดาวน์โหลด (ดูเหมือนว่าจะสามารถเข้าถึง git ได้เท่านั้น)
— Olivier Faucheux
แหล่งที่มา
19
แหล่งที่มา? คุณหมายถึง jar ที่สามารถแนบใน Eclipse มันนี่ BTW: มีอะไรผิดปกติgit clone https://code.google.com/p/guava-libraries/และgit checkout v11.0.2?
— Xaerxess
-7

สิ่งหนึ่งที่น่ารังเกียจเกี่ยวกับฝรั่งคือ Multimap ไม่ได้ขยาย java.util.Map หากคุณมีวิธีการของคุณเองที่ทำงานบนแผนที่พวกเขาจะไม่ทำงานบน Guava Multimaps (ส่วนต่อประสาน Apache MultiMap จะขยาย java.util.Map) ฉันแน่ใจว่ามีเหตุผลที่ดีว่าทำไมมันถึงเป็นอย่างนั้น แต่ก็ไม่สะดวกเช่นกัน

— ด้าน
แหล่งที่มา
16
หากคุณต้องการใช้งานMultimapเช่นMapมีasMap()มุมมองเสมอ
— Xaerxess
22
คุณคาดหวังให้ Multimap ใช้งาน java.util.Map อย่างไร หลายแผนที่แตกต่างจากแผนที่เป็นพื้นฐาน
— sleske
1
Multimap <K, V> ขยาย Map <K, Collection <V>> .. ฉันคิดว่า G มีเหตุผลที่ดีที่จะไม่ใช้ Map เป็น superinterface
— แม
10
@lucek: หากคุณมองผ่าน Javadoc สำหรับMapด้วยความเข้าใจว่าทุกการอ้างอิงถึงVจริงจะเป็นผมคิดว่าคุณจะเห็นสวยได้อย่างรวดเร็วว่าทำไมมันไม่ได้เป็นสิ่งที่ดีสำหรับCollection<V> superinterface Multimap<K, V>
— ruakh
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.