ข้อควรพิจารณาเกี่ยวกับเวอร์ชัน Java ที่จะใช้ในการผลิต

บางคนใช้เทคโนโลยีที่ทันสมัย - อัพเดทวันที่มีการอัพเดท ในการผลิตสิ่งนี้ไม่เหมาะสม

การวิจัยเกี่ยวกับว่าเวอร์ชั่นปัจจุบัน (Java 7) พร้อมสำหรับการผลิตจะสร้างเนื้อหาเก่าจำนวนมากซึ่งอาจไม่ถูกต้องอีกต่อไป (ในขณะที่เขียน Java 7 นี้ออกมานานหนึ่งปีครึ่งซึ่งดูเหมือนนานมาก) .

ฉันต้องพิจารณาอะไรบ้างเพื่อพิจารณาว่าเหมาะสมที่จะอัพเกรดสภาวะแวดล้อมการใช้งานจริงเป็น Java เวอร์ชันใหม่กว่าหรือไม่?

java software-updates production

— JohnDoDo
แหล่งที่มา

แม้ว่าจะเป็นไลบรารี / ปลั๊กอินของบุคคลที่สามใด ๆ ที่ใช้ (ถ้ามี) ในแอปพลิเคชันดังกล่าวจะต้องตกลงกับ Java 7 เช่นกัน (ธุรกิจที่มีความเสี่ยง)

— arin

ใช่. ปัญหาเดียวที่ฉันพบคือฉันไม่สามารถติดตั้ง Java 7 บน Red Hat Enterprise Linux 4 ได้ แต่ระบบปฏิบัติการนั้นล้าสมัยแล้ว ฉันใช้มันในการผลิตทุกที่อื่นประมาณ 6 เดือนแล้วโดยไม่ต้องผูกปม

— GlenPeterson

@arin: ไม่ใช่กับ Java ไม่ใช่จริงๆ มันมีแนวโน้มที่จะลงกันได้อย่างน่าขัน

— Michael Borgwardt

@MichaelBorgwardt ในทางทฤษฎีฉันเห็นด้วยกับคุณ แต่ในสภาพแวดล้อมการทดสอบฉันได้เห็นห้องสมุดบุคคลที่สามทำให้เกิดพฤติกรรมที่ผิดปกติ / ล่มในรหัสทดสอบของเราแม้หลังจากอัปเดตเป็นอัปเกรดเล็ก ๆ

— arin

@arin: แน่นอนมันสามารถเกิดขึ้นได้ แต่จากประสบการณ์ของฉันมันไม่ค่อยมีเหตุผลที่จะกลัวการอัปเดต Java น้อยกว่าการเปลี่ยนแปลงเกือบทุกอย่าง (โดยเฉพาะโค้ดของตัวเอง)

— Michael Borgwardt

คำถามแรกที่ถามคือ "รุ่นของ Java รองรับบนเครื่องหรือไม่" ในขณะที่การอัพเดต JRE เป็นสิ่งหนึ่งอาจเป็นไปได้ว่าระบบปฏิบัติการพื้นฐานไม่รองรับการใช้งานจาวารุ่นใหม่ (รองรับการรับรองและสัญญาการสนับสนุน

สภาพแวดล้อมการผลิตจาวาหลายคนกำลังทำงานจริงด้านบนของแอพพลิเคชันเซิร์ฟเวอร์ นี่จะเป็นการพิจารณาต่อไป การเปรียบเทียบ Wikipedia ของ Java EE App Serversแสดงว่าเวอร์ชันใดของ Java EE ที่รองรับ นี้สามารถเห็นได้ต่อไปในภาพรวมของการทำงานร่วมกันของออราเคิล JavaEE คอนฟิกูเรชันที่ทดสอบแล้วสำหรับJBoss Enterprise Application Platform 6นั้นขัดแย้งกับ Java SE 6.0 update 6u30 ปรับปรุง Java SE 6.0 6u30 ยังคือการกำหนดค่าการทดสอบสำหรับJBoss Application Server 7.1.0 รอบชิงชนะเลิศ สิ่งเหล่านี้อาจทำงานใน Java 7 แต่ไม่ได้ทดสอบการกำหนดค่า

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

ถัดลงมาสายเป็นกรอบ ตัวอย่างหนึ่งคือ JAXB ที่มาพร้อมกับ java และ Spring ที่ใช้ การเปลี่ยนเป็น JAXB ที่อัพเดตของ Java 7 ซึ่งสร้างโค้ดที่เข้ากันไม่ได้กับเฟรมเวิร์กบางตัว (ซึ่งต้องการให้มีการอัพเดต

เครื่องมือสร้างอยู่ถัดจากรายการ หนึ่งจะต้องตรวจสอบให้แน่ใจว่าสภาพแวดล้อมการสร้างใช้รุ่นที่เหมาะสมของ Java การเขียนโค้ดสำหรับ Java 7 แต่ไม่อัปเดตเวอร์ชันที่ Maven หรือ Ant ใช้จะทำให้เกิดปัญหา มีหลายครั้งที่เครื่องมือสร้างตัวเองเชื่อมโยงอย่างแน่นหนากับหนึ่งเวอร์ชันที่มีปลั๊กอินเฉพาะ

เครื่องมือทดสอบ สิ่งต่าง ๆ เช่น PMD, findbugs และ checkstyle อาจไม่รู้จักโครงสร้างใหม่ใน Java เวอร์ชันใหม่ - สิ่งเหล่านี้อาจสับสนมากกับคำสั่ง switch switch หรือการจับแบบผสม เครื่องมือที่เข้าสู่การใช้เครื่องมือเช่นการครอบคลุมโค้ดอาจไม่ทำงานใน JVM ใหม่ ในบริบทของ Java 7, Cobertura และ Emma ไม่ได้รับการอัปเดตเป็น JRE ใหม่ (อีกครั้งแอปพลิเคชันเหล่านี้จะแก้ไขโค้ดไบต์เพื่อดูว่าโค้ดใดทำงานอยู่และไม่ได้อยู่) (ดูไลบรารีโค้ดโอเพนซอร์สสำหรับ jdk7 ) สิ่งนี้อาจต้องการการเปลี่ยนแปลงไปยังสคริปต์การสร้างเพื่อสลับจากที่หนึ่งไปยังอีก

แล้วมีIDE จะต้องอัปเดต IDE เป็นเวอร์ชันที่รับรู้ถึงโครงสร้างใหม่ในภาษา การประกาศการสนับสนุนของ Eclipse สำหรับ Java 7แสดงปัญหาเหล่านี้

ล่าสุดและไม่แน่นอนอย่างน้อยเป็นนักพัฒนา ขึ้นอยู่กับผู้พัฒนาที่จะเขียนรหัสใหม่และระวังว่าจะสามารถปรับโครงสร้างรหัสได้อย่างไร ตั้งแต่ Java 1.4 ถึง 1.5 จะมีการแนะนำเทมเพลตและคำอธิบายประกอบและใช้เวลาสำหรับนักพัฒนาในการทำความเข้าใจกับโครงสร้างใหม่ที่มีอยู่ คอลเลกชันก็ทำใหม่ใน 1.2 และทำให้ผู้พัฒนาไม่ใช้ HashTable และ Vector การอัพเดตเวอร์ชั่นควรมาพร้อมกับจำนวนการฝึกอบรมในโครงสร้างภาษาใหม่

— ชุมชน
แหล่งที่มา