หลังจากพัฒนามาหกเดือน Oracle ได้เปิดตัว Java SE 24 (Java Platform, Standard Edition 24) ซึ่งใช้โครงการโอเพนซอร์ส OpenJDK เป็นแบบอ้างอิง ยกเว้นการลบคุณสมบัติบางอย่างที่เลิกใช้แล้ว Java SE 24 ยังคงรักษาความเข้ากันได้กับเวอร์ชันก่อนหน้าของแพลตฟอร์ม Java โครงการ Java ส่วนใหญ่ที่เขียนไว้ก่อนหน้านี้จะทำงานได้โดยไม่เปลี่ยนแปลงเมื่อใช้งานในเวอร์ชันใหม่ มีไฟล์ติดตั้งพร้อมใช้งานของ Java SE 24 (JDK, JRE และ Server JRE) ไว้ให้แล้ว Linux (x86_64, AArch64) Windows (x86_64) และ macOS (x86_64, AArch64) การพัฒนาโดยโครงการ OpenJDK ทำให้ Java SE 24 เป็นซอฟต์แวร์อ้างอิงแบบโอเพนซอร์สอย่างสมบูรณ์ภายใต้ใบอนุญาต GPLv2 พร้อมด้วยข้อยกเว้น GNU ClassPath ซึ่งอนุญาตให้เชื่อมโยงแบบไดนามิกกับผลิตภัณฑ์เชิงพาณิชย์ได้
Java SE 24 จัดอยู่ในประเภทรุ่นสนับสนุนปกติ โดยมีการเผยแพร่การอัปเดตจนกว่าจะมีการเปิดตัวรุ่นถัดไป สาขาการสนับสนุนระยะยาว (LTS) ควรเป็น Java SE 21 หรือ Java SE 17 ซึ่งจะได้รับการอัปเดตจนถึงปี 2031 และ 2029 ตามลำดับ (โดยทั่วไปจะมีให้ใช้งานจนถึงปี 2028 และ 2026) การสนับสนุนขยายสำหรับสาขา Java SE 8 LTS จะยังคงดำเนินต่อไปจนถึงปี 2030 และ Java SE 11 จะยังคงดำเนินต่อไปจนถึงปี 2032 การเปิดตัว LTS ถัดไปจะเป็นการเปิดตัว Java SE 25 ในฤดูใบไม้ร่วง
ในบรรดา 24 นวัตกรรมที่นำเสนอใน Java SE:
- เสนอโหมดการทำงานเชิงกำเนิดเชิงทดลองของตัวรวบรวมขยะ Shenandoah ซึ่งจะประมวลผลวัตถุเก่าและที่สร้างขึ้นเมื่อเร็วๆ นี้แยกกันเพื่อปรับปรุงประสิทธิภาพในการทำความสะอาดวัตถุที่มีอายุการใช้งานสั้น โหมดใหม่นี้ให้ปริมาณงานที่คาดเดาได้มากขึ้น ความยืดหยุ่นต่อการเปลี่ยนแปลงในการโหลด และลดการใช้หน่วยความจำในระหว่างการรวบรวมขยะ ตัวกำหนดตารางงาน Shenandoah มีเป้าหมายเพื่อลดเวลาหยุดการรวบรวมขยะโดยทำงานควบคู่กันไปกับการทำงานของแอปพลิเคชัน Java มากขึ้น
- JVM ของ HotSpot ใช้การสนับสนุนเชิงทดลองสำหรับส่วนหัวของวัตถุแบบกะทัดรัดซึ่งมีขนาดลดลงจาก 64 บิตเหลือ 96 บิต (64 เหลือ 12 ไบต์) บนระบบ 8 บิต การลดขนาดของส่วนหัวช่วยให้คุณลดขนาดฮีปและปรับปรุงประสิทธิภาพแคช
- ตัวรวบรวมขยะ G1 ได้ลดความซับซ้อนในการนำอุปสรรคที่ตรวจสอบการเข้าถึงหน่วยความจำของแอพพลิเคชั่นไปใช้ ในเวอร์ชันใหม่ การดำเนินการขยายอุปสรรคได้ถูกย้ายไปยังขั้นตอนการคอมไพล์ที่ใหม่กว่าใน C2 JIT การทดสอบแสดงให้เห็นว่าการถ่ายโอนประเภทนี้สามารถลดค่าใช้จ่ายของคอมไพเลอร์ C2 JIT ได้ 10-20% ขึ้นอยู่กับแอปพลิเคชัน
- เพิ่ม API สำหรับใช้ฟังก์ชันการสร้างคีย์การเข้ารหัส (KDF) ซึ่งช่วยให้สามารถสร้างคีย์เพิ่มเติมที่มีความยาวตามต้องการโดยอิงจากคีย์ความลับ (เช่น รหัสผ่าน) และชุดข้อมูลที่ต้องการ ปัจจุบัน API ของ KDF อยู่ในสถานะดูตัวอย่าง
- เพิ่มความสามารถในการโหลดและเชื่อมโยงคลาสแบบล่วงหน้า (Ahead-of-Time) การเปลี่ยนแปลงนี้ช่วยให้ HotSpot JVM เริ่มทำงานได้เร็วขึ้นโดยการจัดเตรียมคลาสที่ใช้ในแอปพลิเคชันที่โหลดและเชื่อมโยงไว้แล้ว เมื่อแอปพลิเคชันเปิดใช้งานครั้งแรก สถานะของคลาสทั้งหมดจะถูกล้างไปยังแคชและใช้เพื่อเร่งความเร็วในการโหลดในการเปิดใช้งานครั้งถัดไป
- เพิ่ม Class-File API สำหรับการแยกวิเคราะห์ การสร้าง และการแปลงไฟล์คลาส Java
ClassFile cf = ClassFile.of(); ClassModel classModel = cf.parse(ไบต์); ไบต์[] newBytes = cf.build(classModel.thisClass().asSymbol(), classBuilder -> { สำหรับ (ClassElement ce : classModel) { ถ้า (!(ce เป็นอินสแตนซ์ของ MethodModel mm และ mm.methodName().stringValue().startsWith(«debug»))) { classBuilder.with(ce); } } });
- มีการเพิ่ม Stream API แบบขยายที่รองรับการกำหนดการดำเนินการระดับกลางของคุณเอง ซึ่งอาจเป็นประโยชน์ในกรณีที่การดำเนินการระดับกลางในตัวที่มีอยู่ไม่เพียงพอสำหรับการแปลงข้อมูลที่ต้องการ ตัวจัดการแบบกำหนดเองจะถูกแนบโดยใช้การดำเนินการระดับกลางใหม่ Stream::gather(Gatherer) ซึ่งประมวลผลองค์ประกอบของสตรีมโดยใช้ตัวจัดการที่ผู้ใช้ระบุกับองค์ประกอบเหล่านี้ jshell> สตรีมของ (1,2,3,4,5,6,7,8,9).gather(หน้าต่างใหม่คงที่ (3)).toList() $1 ==> [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
- มีการเสนอการใช้งาน Scoped Values เบื้องต้นครั้งที่สี่ ซึ่งจะทำให้สามารถแชร์ข้อมูลที่ไม่เปลี่ยนแปลงได้ระหว่างเธรดต่างๆ และแลกเปลี่ยนข้อมูลอย่างมีประสิทธิภาพระหว่างเธรดย่อย (ค่าต่างๆ จะได้รับการสืบทอด) ค่าขอบเขตกำลังพัฒนาเพื่อแทนที่กลไกตัวแปรภายในเธรด และมีประสิทธิภาพมากขึ้นเมื่อใช้เธรดเสมือนจำนวนมาก (หลายพันหรือหลายล้านเธรด) ความแตกต่างหลักระหว่างค่าขอบเขตและตัวแปรภายในเธรดคือ ค่าขอบเขตจะถูกเขียนเพียงครั้งเดียว ไม่สามารถเปลี่ยนแปลงได้ในภายหลัง และจะพร้อมใช้งานเฉพาะระหว่างระยะเวลาที่เธรดดำเนินการเท่านั้น
- กลไกการจับคู่รูปแบบได้รับการอัปเดตเพื่อรวมการสนับสนุนเบื้องต้นสำหรับการใช้ประเภทดั้งเดิม (int, byte, char และประเภทที่ไม่ใช่วัตถุพื้นฐานอื่น ๆ ) ในประเภทเทมเพลตทั้งหมด ตัวดำเนินการ instanceof และบล็อกสวิตช์ สวิตช์ (x.getStatus()) { กรณี 0 -> "โอเค"; กรณีที่ 1 -> «คำเตือน»; กรณีที่ 2 -> «ข้อผิดพลาด»; กรณี int i -> "สถานะไม่ทราบ: " + i; } if (i เป็นอินสแตนซ์ของไบต์ b) { … b … }
- นี่คือร่างที่เก้าของ Vector API ซึ่งให้ฟังก์ชันสำหรับการคำนวณเวกเตอร์ที่ดำเนินการโดยใช้คำสั่งเวกเตอร์ของโปรเซสเซอร์ x86_64 และ AArch64 และอนุญาตให้นำการดำเนินการไปใช้กับค่าหลายค่าได้ในคราวเดียว (SIMD) ต่างจากการสร้างเวกเตอร์อัตโนมัติของคอมไพเลอร์ HotSpot JIT สำหรับการดำเนินการสเกลาร์ API ใหม่นี้ให้ความสามารถในการควบคุมการสร้างเวกเตอร์อย่างชัดเจนสำหรับการประมวลผลข้อมูลแบบขนาน
- รองรับการซิงโครไนซ์เธรดเสมือนโดยไม่ต้องปักหมุดไว้กับเธรดเฉพาะแพลตฟอร์ม ตอนนี้เธรดเสมือนในวิธีการแบบซิงโครไนซ์หรือการแสดงออกในสถานะถูกบล็อคจะปล่อยเธรดแพลตฟอร์มของตนเอง ซึ่งทำให้เธรดเสมือนอื่นสามารถใช้ได้ ทำให้จำนวนเธรดเสมือนที่พร้อมใช้งานเพิ่มขึ้นอย่างมีนัยสำคัญ และปรับปรุงการปรับขยายขนาดของแอปพลิเคชันที่ใช้มัลติเธรด
- เพิ่มแบบร่างที่สามของฟีเจอร์ที่อนุญาตให้ตัวสร้างระบุนิพจน์ก่อนเรียก super(…) เพื่อเรียกตัวสร้างคลาสหลักจากตัวสร้างคลาสที่สืบทอดมาโดยชัดเจน ตราบใดที่นิพจน์เหล่านั้นไม่อ้างอิงถึงอินสแตนซ์ที่ตัวสร้างสร้างขึ้น คลาส Outer { void hello() { System.out.println("สวัสดี"); } คลาส Inner { Inner() { สวัสดี(); ซุปเปอร์(); -
- ยูทิลิตี้ Jlink รองรับการสร้างภาพรันไทม์โดยไม่ใช้ไฟล์ JMOD ซึ่งช่วยลดขนาดของ JDK ลงได้ประมาณ 25%
- เพิ่มร่างที่สองของการใช้คำสั่ง "import module M" เพียงคำสั่งเดียวเพื่อนำเข้าแพ็กเกจทั้งหมดที่ส่งออกโดยโมดูลที่ระบุในครั้งเดียว การเปลี่ยนแปลงนี้ทำให้สามารถนำไลบรารีโมดูลาร์มาใช้ซ้ำได้ง่ายยิ่งขึ้น โดยอนุญาตให้รวมไลบรารีและคลาสได้โดยไม่ต้องระบุตำแหน่งของไลบรารีและคลาสเหล่านั้นในลำดับชั้นของแพ็กเกจ ตัวอย่างเช่น การระบุ "import module java.base" จะนำเข้าแพ็กเกจทั้งหมด 54 แพ็กเกจที่รวมอยู่ในโมดูล java.base ซึ่งก่อนหน้านี้จะต้องระบุไว้แยกต่างหาก ("import java.io.*", "import java.util.*" เป็นต้น)
- เพิ่มการใช้งานเบื้องต้นที่สี่ของคลาสที่ประกาศโดยนัยและอินสแตนซ์ที่ไม่ได้ตั้งชื่อของวิธี "main" ซึ่งสามารถทำได้โดยไม่ต้องใช้การประกาศสาธารณะ/แบบคงที่ การส่งอาร์เรย์ของอาร์กิวเมนต์ และเอนทิตีอื่น ๆ ที่เกี่ยวข้องกับการประกาศคลาส // เป็นคลาสสาธารณะ HelloWorld { public static void main(String[] args) { System.out.println(«Hello world!»); } } // ตอนนี้คุณสามารถ void main() { System.out.println(«Hello, World!»); -
- ตอนนี้ร่างที่สี่ของ Structured Concurrency API ซึ่งลดความซับซ้อนในการพัฒนาแอปพลิเคชันมัลติเธรดโดยการถือว่างานหลายงานที่ทำงานบนเธรดที่แตกต่างกันเป็นหน่วยเดียว พร้อมสำหรับการทดสอบแล้ว
- ขณะนี้ API KeyPairGenerator, Signature และ KeyFactory รองรับอัลกอริทึม ML-KEM (CRYSTALS-Kyber) และ ML-DSA (CRYSTALS-Dilithium) ซึ่งได้รับการกำหนดมาตรฐานโดยสถาบันมาตรฐานและเทคโนโลยีแห่งชาติของสหรัฐอเมริกา (NIST) และทนทานต่อการโจมตีแบบบรูทฟอร์ซบนคอมพิวเตอร์ควอนตัม อัลกอริทึมเหล่านี้ใช้การเข้ารหัสวิธีโดยอิงจากการแก้ปัญหาตามทฤษฎีแลตทิซ ซึ่งเวลาในการแก้ปัญหานั้นเท่ากันทั้งบนคอมพิวเตอร์ทั่วไปและคอมพิวเตอร์ควอนตัม
- ในตัวรวบรวมขยะ ZGC การสนับสนุนสำหรับโหมดการทำงานที่ไม่สร้าง ซึ่งไม่แยกการประมวลผลของวัตถุ "เก่า" และ "ใหม่" ได้ถูกลบออก ตั้งแต่ Java SE 23 เป็นต้นไป โหมดสร้างของ ZGC จะเป็นค่าเริ่มต้น
- เพิ่มคำเตือนเกี่ยวกับการใช้ JNI (Java Native Interface) และ FFM (Foreign Function & Memory) API เพื่อเตรียมนักพัฒนาให้พร้อมสำหรับการเข้าถึงข้อมูล API แบบจำกัดเนื่องจากมีการรวมโหมดความสมบูรณ์ไว้ในรุ่นที่จะออกในอนาคตซึ่งห้ามการโต้ตอบกับโค้ดเนทีฟตามค่าเริ่มต้น
- เปิดใช้งานเอาต์พุตคำเตือนเมื่อใช้เมธอดการเข้าถึงหน่วยความจำภายนอก (นอก JVM) ที่จัดทำโดยคลาส sun.misc.Unsafe หากต้องการเข้าถึงหน่วยความจำนอกฮีปและโต้ตอบกับโค้ดภายนอก ขอแนะนำให้ใช้ VarHandle API ในรุ่นก่อนหน้านี้ การสนับสนุน sun.misc.Unsafe ไม่ได้รับการสนับสนุนอีกต่อไป
- Disabled Security Manager ซึ่งสูญเสียความเกี่ยวข้องมาเป็นเวลานานและไม่เป็นที่ต้องการอีกต่อไปหลังจากที่การสนับสนุนปลั๊กอินเบราว์เซอร์สิ้นสุดลง Security Manager ถูกยกเลิกใน Java 17 แล้ว และมีแผนที่จะลบรหัส Security Manager ออกอย่างสมบูรณ์ในรุ่นถัดไป
- ลบโค้ดเพื่อรองรับระบบปฏิบัติการ 32 บิต Windows บนระบบ x86 พอร์ต Java สำหรับระบบ x86 32 บิตนั้นล้าสมัยแล้วและมีกำหนดจะถูกลบออก (การสนับสนุนจะยุติลง) Linux (บนระบบ x86 32 บิต)
นอกจากนี้ เรายังสามารถสังเกตการเผยแพร่การอัพเดตของแพลตฟอร์มสำหรับการสร้างแอปพลิเคชันที่มีอินเทอร์เฟซแบบกราฟิก JavaFX 24 และการเปิดตัวเครื่องเสมือนสากล GraalVM ใหม่ ซึ่งรองรับการรันแอปพลิเคชันใน JavaScript (Node.js), Python, Ruby, R, ภาษาใด ๆ สำหรับ JVM (Java, Scala, Clojure, Kotlin) และภาษาที่สามารถสร้างบิตโค้ด LLVM ได้ (C, C++, Rust) นอกเหนือจากการรองรับ JDK 24 แล้ว GraalVM เวอร์ชันใหม่ยังมีการเพิ่มประสิทธิภาพสำหรับงานการเรียนรู้ของเครื่อง การสนับสนุนที่ดีขึ้นสำหรับการคอมไพล์ไบต์โค้ด Java เป็นโค้ดเครื่อง และกลไก SkipFlow เพื่อลดขนาดของไฟล์ปฏิบัติการและลดเวลาในการคอมไพล์
ที่มา: opennet.ru
