การอัพเกรดโค้ดที่คอมไพล์ Java 7 เป็น Java 8 มีประโยชน์หรือไม่?

ฉันมีแอปพลิเคชันเก่าที่เขียนโดยใช้ Java 7 มันทำงานได้ดีใน Java 8 JRE ฉันไม่ได้วางแผนที่จะเขียนโค้ดใหม่เพื่อใช้ประโยชน์จากคุณสมบัติ Java 8 มีประโยชน์ทางเทคนิคในการอัพเกรดโค้ดที่คอมไพล์แล้วเป็น Java 8 JDK ล่าสุดหรือไม่?

เพื่อความชัดเจนขณะนี้โค้ดถูกคอมไพล์ด้วย Java 7 และรันด้วย Java 8 JRE ล่าสุดแล้ว ควรได้รับประโยชน์จากการปรับปรุงรันไทม์ Java 8 อยู่แล้ว คำถามนี้คือประโยชน์ที่จะได้รับจากการคอมไพล์ด้วยเวอร์ชัน 8 และรันด้วยโค้ดไบต์คอมไพล์ Java 8 หรือไม่

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

ถ้าฉันเข้าใจคำถามอย่างถูกต้องคุณต้องการทราบว่า bytecode ที่สร้างโดยjavacJava 8 จะ "ดีกว่า" ใน Java 7 หรือไม่

คำตอบคืออาจไม่ใช่พวกเขาแก้ไขข้อบกพร่องในคอมไพเลอร์อย่างต่อเนื่องและบางครั้งก็นำไปสู่ ​​bytecode ที่มีประสิทธิภาพมากขึ้น แต่คุณจะไม่เห็นการเร่งความเร็วที่สำคัญจากการแก้ไขเหล่านี้สำหรับ Java 8 เท่าที่ฉันเห็นบันทึกการเปลี่ยนแปลงจะแสดงรายการการเปลี่ยนแปลงที่สำคัญ 2 รายการระหว่างเวอร์ชันเท่านั้น

เว็บไซต์ Oracle เป็นที่น่ากลัวและฉันไม่สามารถดูเหมือนจะได้รับรายชื่อของการแก้ไขข้อบกพร่องที่เกี่ยวข้องกับการjavacระหว่างรุ่น แต่ที่นี่เป็นหนึ่งที่ครบถ้วนสมบูรณ์ไม่ใช่จาก OpenJDK สิ่งที่ฉันจัดการได้ส่วนใหญ่พบคือการแก้ไขข้อผิดพลาด ดังนั้นการอัปเดตเป็น Java 8 จึงมีโอกาสที่จะไม่คอมไพล์อีกต่อไปเนื่องจากการปฏิบัติjavacตาม JLS อย่างถูกต้องมากขึ้นและจะมีการ "ปรับปรุง" ไบต์โค้ดน้อยมากที่ไม่มีเลย

ประโยชน์หลักคือ Java 8 มีการแก้ไขข้อบกพร่องล่าสุดโดยที่ Java 7 ไม่ได้รับการอัปเดตต่อสาธารณะ

นอกจากนี้หากคุณกำลังจะรันโค้ดบน Java 8 JVM คุณอาจติดตั้ง Java เพียงเวอร์ชันเดียว

Java 8 อาจเร็วกว่าและรองรับคุณสมบัติใหม่ ๆ เช่น G1 ได้ดีกว่า อย่างไรก็ตามกรณีการใช้งานของคุณอาจช้าลงดังนั้นวิธีเดียวที่จะทราบได้คือการทดสอบ

มีประโยชน์ทางเทคนิคในการอัพเกรดโค้ดที่คอมไพล์แล้วเป็น Java 8 JDK ล่าสุดหรือไม่?

หากคุณกำลังถามว่าการคอมไพล์โค้ด Java 7 ใหม่ในคอมไพเลอร์ Java 8 มีประโยชน์หรือไม่คำตอบคือ แทบไม่มีอะไรเลย

ข้อแตกต่างที่ลึกซึ้งเพียงอย่างเดียวคือมีความแตกต่างเล็กน้อยกับ Java API ดังนั้นอาจมีความแตกต่างเล็กน้อยคอมไพเลอร์ Java 8 อาจพบว่า Java 7

ความแตกต่างเล็กน้อยอื่น ๆ คือหมายเลขวิเศษที่จุดเริ่มต้นของไฟล์ซึ่งอาจเป็นลำดับของพูลคงที่ โดยพื้นฐานแล้วรหัสไบต์นั้นเหมือนกันแม้กระทั่งการรองรับinvokedynamicที่เพิ่มสำหรับ lambdas ก็มีอยู่ใน Java 7 แต่ก็ไม่ได้ใช้แบบนั้น

มันอาจช่วยให้โดยการสร้างความตระหนัก

เมื่อคุณเปลี่ยนไปใช้ Java8 คุณอาจพบคำเตือนเพิ่มเติมที่ปล่อยออกมาโดย javac ตัวอย่าง: การอนุมานประเภทได้รับการปรับปรุงอย่างมากด้วย Java8 และนั่นสามารถขจัดความจำเป็นในการใช้คำอธิบายประกอบ @SuppressWarnings ในฐานรหัสปัจจุบันของคุณ (และเมื่อไม่จำเป็นต้องใช้คำอธิบายประกอบดังกล่าวอีกต่อไปคอมไพเลอร์จะเตือนเกี่ยวกับเรื่องนั้น)

ดังนั้นแม้ว่าคุณจะไม่ได้ตั้งใจจะแก้ไขฐานรหัสของคุณในวันนี้การเปลี่ยนไปใช้ Java8 ก็สามารถบอกคุณได้ การเพิ่มพูนความรู้สามารถช่วยในการตัดสินใจอย่างมีข้อมูล

ในทางกลับกัน:

• ฉันเห็นคำถามบางอย่างเกี่ยวกับสถานการณ์ (หายาก) ที่ Java8 ปฏิเสธที่จะคอมไพล์โค้ด Java7 ดังนั้นการเปลี่ยนไปใช้ Java8 ยังมีความเสี่ยง (น้อยที่สุด) ที่จะพบปัญหาประเภทนั้น
• และ: แม้ว่าคุณจะไม่ได้ตั้งใจจะแตะฐานรหัสของคุณในวันนี้แต่ก็มีโอกาสที่คุณจะเปลี่ยนใจในภายหลัง จากนั้นเมื่อไม่ใส่ใจคุณอาจใช้ประโยชน์จากคุณสมบัติ Java8 ซึ่งอาจทำให้ "การอัปเดตฟิลด์" ซับซ้อน; เนื่องจากตอนนี้คุณมีซอร์สโค้ดสองเวอร์ชันที่ต้องดูแล!
• จากนั้น: ในกรณีที่คุณมีลูกค้าเรียกใช้ผลิตภัณฑ์โดยใช้ java7 jre; คุณต้องระวังอย่างมากเกี่ยวกับการแก้ไขไบนารีที่คุณให้กับพวกเขา เรามีการตั้งค่าดังกล่าว และฉันเสียเวลาไปมากกว่าหนึ่งครั้งเพราะบังเอิญใส่คลาสที่คอมไพล์ Java8 ตัวเดียวลงในระบบทดสอบที่ขับเคลื่อนด้วย Java7 โดยไม่ได้ตั้งใจ นั่นไม่สามารถเกิดขึ้นได้เมื่อการตั้งค่า dev และการทดสอบ / ลูกค้าของคุณเป็น Java7 ทั้งหมด

เรื่องสั้นขนาดยาว: มีข้อดีเล็กน้อยและความเสี่ยงบางอย่าง (ซึ่งความสำคัญของความเสี่ยงส่วนใหญ่ขึ้นอยู่กับการตั้งค่าโดยรวมของคุณ)

ฉันจะทำเพื่อข้อเท็จจริงเหล่านี้เป็นอย่างน้อย

1) HashMap ภายใน (เร็วกว่าภายใต้ jdk-8)

2) แก้ไขข้อบกพร่องจำนวนมากที่อาจโปร่งใสสำหรับคุณ (การเพิ่มประสิทธิภาพรันไทม์) ซึ่งจะทำให้โค้ดของคุณเร็วขึ้นและดีขึ้นโดยที่คุณไม่ต้องทำอะไรเลย

3) G1 เครื่องเก็บขยะ

แก้ไข

จากมุมมองทางเทคนิคสิ่งนี้ดูเหมือนจะทำกับAhead of Time Compilationหรือสิ่งที่คอมไพเลอร์อาจปรับปรุงโดยการวิเคราะห์โค้ดให้มากขึ้น เท่าที่ฉันรู้สิ่งเหล่านี้ไม่ได้ทำในคอมไพเลอร์ java 8

จากมุมมองของนักพัฒนา - มีมากมาย ผลผลิตที่เพิ่มขึ้นเป็นสิ่งที่สำคัญที่สุดสำหรับฉัน

แก้ไข 2

ฉันรู้เพียงสองจุดที่ตรงกับคำถามที่สองของคุณ:

-parameters

เพื่อรักษาชื่อพารามิเตอร์เมธอด

-ข้อมูลส่วนตัว

เรียกว่าCompact Profile Optionสำหรับพื้นที่ขนาดเล็ก

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

อย่างไรก็ตามหากคุณต้องคอมไพล์ใหม่เพียงครั้งเดียวให้พิจารณาสิ่งนี้:

• ซอร์สโค้ดแอปพลิเคชันของคุณเข้ากันได้กับ Java 7 และน่าจะเป็น 8 ด้วย
• ในกรณีที่โค้ดไม่ได้คอมไพล์กับ Java 8 อาจไม่สามารถคอมไพล์กับคอมไพเลอร์ Java 8 ในโหมดความเข้ากันได้ของซอร์ส Java 7 ( -source 7พร้อม javac)
• นักพัฒนาและ CI ของคุณจะต้องรันยูนิตและการทดสอบการรวมกับรันไทม์ Java 8 เพื่อให้ใกล้เคียงกับสภาพแวดล้อมการใช้งานจริงมากที่สุด นักพัฒนาจะต้องเรียกใช้แอปพลิเคชันบนรันไทม์ Java 8 เดียวกันเมื่อเรียกใช้ภายในเครื่อง
• การคอมไพล์ด้วย JDK 7 และรันด้วย JRE 8 (ในกระบวนการสร้างเดียวกันหรือใน IDE เดียวกัน) ทำได้ยากกว่าการทำทุกอย่างด้วยเวอร์ชันเดียวกัน
• ไม่มีประโยชน์ในการใช้-source 7แทน-source 8หากคุณคอมไพล์ด้วย JDK 8 และรันไทม์เป้าหมายของคุณคือ Java 8
• การใช้การ-source 8รับประกันว่าผู้พัฒนาใช้ Java 8 (หรือใหม่กว่า) สำหรับทั้งการคอมไพล์และรันไทม์ (ตามที่บังคับใช้-target 8)

สรุปได้ว่าอย่าคอมไพล์ใหม่ถ้าคุณไม่จำเป็นต้องทำ อย่างไรก็ตามในครั้งแรกที่คุณต้องคอมไพล์ใหม่ (เนื่องจากการเปลี่ยนแปลงโค้ด) ให้เปลี่ยนไปใช้ Java 8 อย่าเสี่ยงที่จะมีข้อบกพร่องเนื่องจากสภาพแวดล้อมไม่ตรงกันและอย่า จำกัด นักพัฒนาโดยไม่มีเหตุผลที่ดี