อะไรคือการปรับปรุงครั้งใหญ่ระหว่างไลบรารีที่เทียบเท่ากับ guava และ apache


123

ขณะนี้เราใช้คอลเลกชัน apache, เครื่องมือสตริงและอื่น ๆ ฉันต้องตัดสินใจว่าเราควรเปลี่ยนจากการใช้ฐานรากของ apache หรือไม่

เกณฑ์ที่สำคัญคือความสะดวกในการใช้งานของนักพัฒนา การใช้งานประสิทธิภาพ / หน่วยความจำยังไม่ใช่ประเด็นสำคัญสำหรับเรา ความเร็วของการพัฒนาเป็นเกณฑ์สำคัญในจุดนี้

ฉันขอขอบคุณความคิดเห็นเกี่ยวกับวิธีการที่ชีวิตของนักพัฒนากลายเป็นเรื่องง่ายขึ้นอย่างมากกับฝรั่ง

คำตอบ:


223

ก่อนอื่นตามที่javamonkey79อธิบายไว้ในขณะที่ Google Guava และ Apache Commons ใช้คุณลักษณะที่คล้ายกัน แต่ทั้งคู่ยังมีฟังก์ชันการทำงานที่ขาดหายไปจากคู่ของตน ดังนั้นการ จำกัด ตัวเองให้อยู่ในห้องสมุดเพียงแห่งเดียวอาจไม่ฉลาด

ที่ถูกกล่าวว่าถ้าฉันต้องเลือกฉันจะเลือกใช้ Guava โดยคง Apache Commons ไว้สำหรับกรณี (หายาก) ที่ Guava ไม่มีฟังก์ชันที่จำเป็น ให้ฉันพยายามอธิบายว่าทำไม

ฝรั่งมัน "ทันสมัย" กว่า

Apache Commons เป็นไลบรารีสำหรับผู้ใหญ่จริงๆ แต่ก็มีอายุเกือบ 10 ปีและกำหนดเป้าหมายเป็น Java 1.4 ฝรั่งก็เปิดมาในปี 2007เป้าหมาย Java 5 และทำให้ฝรั่งประโยชน์อย่างมากจากชวา 5 คุณสมบัติ: ข้อมูลทั่วไป , varargs , enumsและ autoboxing

นักพัฒนา Guava กล่าวว่ายาชื่อสามัญเป็นเหตุผลหนึ่งที่พวกเขาเลือกที่จะสร้างไลบรารีใหม่แทนที่จะปรับปรุง Apache Commons (ดูคำถามที่พบบ่อยเกี่ยวกับคอลเล็กชันของGoogleภายใต้หัวข้อ"ทำไม Google จึงสร้างทั้งหมดนี้ในเมื่อมันสามารถพยายามปรับปรุง Apache ได้ Commons Collections แทนหรือไม่ " )

ฉันเห็นด้วยกับพวกเขา: ในขณะที่มักถูกวิพากษ์วิจารณ์ (ไม่มีการทำให้ซ้ำถูก จำกัด เนื่องจากความเข้ากันได้แบบย้อนหลัง) Java generics ยังคงมีประโยชน์มากเมื่อใช้อย่างเหมาะสมเช่นเดียวกับที่ฝรั่งทำ ฉันอยากจะลาออกมากกว่าที่จะทำงานกับคอลเลกชันที่ไม่ได้เปิดเผย!

(หมายเหตุว่า Apache Commons 3.0 ไม่เป้าหมาย Java 1.5+)

ฝรั่งออกแบบ / จัดทำเอกสารได้ดีมาก

โค้ดนี้เต็มไปด้วยแนวทางปฏิบัติที่ดีที่สุดและรูปแบบที่เป็นประโยชน์เพื่อให้ API อ่านได้ง่ายขึ้นค้นพบประสิทธิภาพปลอดภัยเธรดปลอดภัย ...

หลังจากอ่านEffective Java (BTW หนังสือที่ยอดเยี่ยม) ฉันเห็นรูปแบบเหล่านี้ทุกที่ในโค้ด:

  • วิธีการโรงงาน (เช่นImmutableList.copyOf())
  • รูปแบบการสร้าง ( ImmutableList.builder(), Joiner, CharMatcher, Splitter, Ordering, ... )
  • เปลี่ยนไม่ได้ (คอลเลกชันไม่เปลี่ยนรูปCharMatcher, Joiner, Splitter, ... )
  • การซ่อนการใช้งาน ( Predicates.xXx, ... )
  • ชอบการแต่งเพลงมากกว่ามรดก ( ForwardXXXคอลเลกชัน)
  • ด้วย null ตรวจสอบ
  • รูปแบบ enum-singleton
  • พร็อกซีการทำให้เป็นอนุกรม
  • หลักการตั้งชื่อที่คิดออกมาเป็นอย่างดี

ฉันสามารถอธิบายข้อดีของการออกแบบเหล่านี้ได้หลายชั่วโมง (บอกฉันว่าคุณต้องการให้ฉันทำหรือไม่) สิ่งนี้ก็คือรูปแบบเหล่านี้ไม่เพียง แต่ "เพื่อการแสดง" เท่านั้น แต่ยังมีคุณค่าที่แท้จริง: API มีความสุขในการใช้งานเรียนรู้ได้ง่ายขึ้น (ฉันลืมที่จะบอกว่าเอกสารนั้นดีเพียงใด) มีประสิทธิภาพมากขึ้นและ หลายคลาสนั้นง่ายกว่า / เธรด - ปลอดภัยเนื่องจากไม่เปลี่ยนรูป

ในฐานะที่เป็นจุดโบนัสหนึ่งจะได้เรียนรู้มากมายโดยดูที่รหัส :)

ฝรั่งมีความสม่ำเสมอ

Kevin Bourrillion (ผู้พัฒนาหลักของ Guava) ทำงานได้อย่างยอดเยี่ยมในการรักษาคุณภาพ / ความสม่ำเสมอในระดับสูงทั่วทั้งห้องสมุด แน่นอนว่าเขาไม่ได้อยู่คนเดียวและมีนักพัฒนาที่ยอดเยี่ยมมากมายให้การสนับสนุน Guava (แม้แต่Joshua Blochซึ่งตอนนี้ทำงานที่ Google!)

ปรัชญาหลักและตัวเลือกการออกแบบที่อยู่เบื้องหลังฝรั่งมีความสอดคล้องกันในห้องสมุดและนักพัฒนาที่เป็นไปตามที่ดี (IMO) หลักการออกแบบ API มากมีการเรียนรู้จากความผิดพลาดที่ผ่านมาของ JDK APIs (ไม่ใช่ของพวกเขาผิดพลาดแม้ว่า)

ฝรั่งมีอัตราส่วนกำลังต่อน้ำหนักสูง

นักออกแบบฝรั่งต่อต้านการล่อลวงในการเพิ่มคุณสมบัติมากเกินไปโดย จำกัด API ให้เป็นประโยชน์สูงสุด พวกเขารู้ว่ามันยากมากที่จะลบคุณลักษณะครั้งเพิ่มและทำตามคำขวัญของโจชัวโบลชกับการออกแบบ API: "เมื่อสงสัยปล่อยให้มันออก" นอกจากนี้การใช้คำอธิบายประกอบ @Beta ช่วยให้พวกเขาทดสอบตัวเลือกการออกแบบบางส่วนโดยไม่ก่อเฉพาะ API

ตัวเลือกการออกแบบที่กล่าวถึงข้างต้นอนุญาตให้ใช้ API ที่กะทัดรัดมาก เพียงแค่มองไปที่MapMakerเพื่อดูขุมพลังที่อัดแน่นอยู่ในตัวสร้าง "แบบธรรมดา" ที่ดีอื่น ๆ (แม้จะง่าย?) ตัวอย่างCharMatcher , Splitterและการสั่งซื้อ

นอกจากนี้ยังง่ายมากที่จะแต่งส่วนต่างๆของ Guava ตัวอย่างเช่นคุณต้องการแคชผลลัพธ์ของฟังก์ชันที่ซับซ้อนหรือไม่? ป้อนฟังก์ชันนี้ให้กับ MapMaker และ BINGO ของคุณคุณจะได้รับแผนที่ / แคชคอมพิวเตอร์แบบเธรดที่ปลอดภัย ต้องการ จำกัด อินพุตแผนที่ / ฟังก์ชันไปยังสตริงเฉพาะหรือไม่? ไม่มีปัญหาห่อไว้ในConstrainedMapโดยใช้CharMatcherเพื่อปฏิเสธสตริงที่ไม่เหมาะสม ...

ฝรั่งกำลังอยู่ในช่วงพัฒนางาน

ในขณะที่การพัฒนา Apache Commons ดูเหมือนจะเร่งขึ้นด้วยการทำงานบน Commons Lang 3.0 แต่ Guava ดูเหมือนจะได้รับไอน้ำมากขึ้นในขณะที่ Google เปิดแหล่งที่มาของคลาสภายในมากขึ้น

เนื่องจาก Google พึ่งพาภายในอย่างมากฉันจึงไม่คิดว่ามันจะหายไปในเร็ว ๆ นี้ พลัสเปิดห้องสมุดจัดหาสามัญของ บริษัท ช่วยให้ Google ไปยังแหล่งอื่น ๆ ได้อย่างง่ายดายเปิดอื่น ๆห้องสมุดที่ขึ้นอยู่กับมัน (แทนrepackagingพวกเขาเช่น Guice ปัจจุบันไม่ )

ข้อสรุป

ด้วยเหตุผลข้างต้น Guava จึงเป็นไลบรารี go-to ของฉันเมื่อเริ่มโปรเจ็กต์ใหม่ และฉันรู้สึกขอบคุณ Google และผู้พัฒนา Guava ที่ยอดเยี่ยมผู้สร้างห้องสมุดที่ยอดเยี่ยมนี้


PS: คุณอาจต้องการอ่านคำถามอื่น ๆ นี้

PPS: ฉันไม่ได้เป็นเจ้าของหุ้นของ Google (ยัง)


ขอบคุณ! * หน้าแดง * ฉันเพิ่งแก้ไขคำตอบเพื่อพูดคุยเพิ่มเติมเกี่ยวกับการพัฒนาที่กระตือรือร้นของ Guava และเพื่อให้รายละเอียดคุณสมบัติ Java 1.5 ดีขึ้น
Etienne Neveu

1
เพิ่งสังเกตว่า Kevin Bourrillion พูดถึง Guava vs Apache Commons ในการพูดคุยนี้: youtube.com/watch?v=9ni_KEkHfto#t=42m38s
Etienne Neveu

หมายเหตุอย่างหนึ่ง Guava เปลี่ยน API และเลิกใช้วิธีการเดิม ๆ บ่อยครั้งดังนั้นการพึ่งพาอาจทำให้เกิดปัญหาเช่นการล็อกเวอร์ชันและความเข้ากันไม่ได้กับไลบรารีของบุคคลที่สามอื่น ๆ ที่ใช้ Guava
Archimedes Trajano

24

ผมใช้ฝรั่งมาตั้งแต่ ส.ค. 2010 เริ่มจากรุ่น r06 โดยพื้นฐานแล้วฉันมีไลบรารี greenfield java เพื่อพัฒนาดังนั้นฉันจึงมองหาไลบรารีเสริมที่ดีที่สุดสำหรับ J2SE API ตามเนื้อผ้าเราใช้ไลบรารีของ Apache Commons แต่ฉันอยากเห็นว่ามีอะไรอยู่บ้างและเริ่มใช้ Guava

ข้อดี

  1. โครงสร้างภาษา Java 5.0 ไลบรารีใช้ตัวชี้นำการออกแบบส่วนใหญ่มาจาก "Effective Java: 2nd Edition" ของ Bloch: ความไม่เปลี่ยนรูปแบบตัวสร้างโรงงานแทนตัวสร้าง Generics ฯลฯ สิ่งนี้ทำให้โค้ดของคุณรัดกุมและแสดงออกมากขึ้น
  2. รองรับการเขียนโปรแกรมเชิงฟังก์ชันโดยเฉพาะอย่างยิ่งกับอินเทอร์เฟซ Function ระดับบนสุดและ Predicate

จุดด้อย

  1. การทดแทน Apache Commons ไม่เพียงพอโดยเฉพาะอย่างยิ่งตัวแปลงสัญญาณคอมมอนส์
  2. ไม่มี 'ตำราฝรั่ง' ห้องสมุดมีทั้งแบบเรียบง่ายและตั้งฉากกัน ดังนั้นจึงมีช่วงการเรียนรู้ที่ชัดเจนเพื่อใช้ประโยชน์จากมันอย่างเต็มที่ ดังที่ได้กล่าวไปแล้ว Javadoc นั้นยอดเยี่ยม แต่กรณีศึกษาซอร์สโค้ดที่ยาวกว่าจะเป็นประโยชน์
  3. หากคุณอยู่ในสภาพแวดล้อมที่ต้องใช้ Java 1.3 หรือ 1.4 คุณก็โชคไม่ดี

สำหรับฉันแล้ว Guava ทำให้ Java รู้สึกใกล้ชิดกับภาษาสคริปต์ที่สั้นมากขึ้นและนั่นก็เยี่ยมมาก


16

จากประสบการณ์ของฉันฉันไม่เข้าใจว่าพวกเขาต่อสู้กันเองหรือฝรั่งปรับปรุงใน apache libs แต่ฝรั่งมาเติมเต็ม apache libs มีคลาสและยูทิลิตี้ฝรั่งที่ไม่มีใน apache และในทางกลับกัน

ดังนั้นฉันไม่รู้ว่าคุณต้องเปลี่ยนตามตัว - ฉันจะบอกว่า "ใช้เครื่องมือที่เหมาะสมสำหรับงานที่เหมาะสม"


1
ฉันได้ข้อสรุปนี้เมื่อไม่นานมานี้หลังจากเห็นว่า Guava ไม่มีอะไรใกล้เคียงกับสิ่งที่ Apache เสนอใน FileNameUtils (ใช่มีการทับซ้อนกัน แต่ FileNameUtils ของ Apache มีมากกว่า Guava's Files มากทำไม Google ถึงต้องใช้Filesตอนนี้ทุกเวลาที่ฉันต้องการ ในการใช้ JDK Filesฉันต้องเขียนเส้นทางทั้งหมด ... ) แอพของฉันต้องการยูทิลิตี้ไฟล์จำนวนมากดังนั้นฉันจึงไม่สามารถหลีกเลี่ยงการใช้ Apache ในกรณีนี้ได้
Don Cheadle
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.