إصدار Java 27 يغيّر افتراضيين: G1 في كل البيئات وcompact object headers
الترقية هذه المرة ليست السلوك نفسه بسرعة أعلى، فهناك افتراضيان تغيّرا ويطبقان دون أي إجراء، والحكم عليهما يأتي من قياس الأداء على كل تطبيق لا من ملاحظات الإصدار.
وصل JDK 27 إلى مرحلة General Availability في 15 سبتمبر 2026، بحسب صفحته الرسمية على openjdk.org، التي تعدد 9 مقترحات JEP. واثنان منها يغيّران السلوك الافتراضي، أي أنهما يسريان دون أن يفعل المطور شيئًا.
الأول JEP 523، الذي يجعل G1 هو الـ garbage collector الافتراضي في كل البيئات. فقبل ذلك، كانت الـ JVM تختار Serial GC تلقائيًا في بعض الحالات، حين يكون الجهاز صغيرًا أو عدد الأنوية قليلًا، دون أن يلاحظ المطور. هذا الاستثناء انتهى.
والثاني JEP 534، الذي يجعل compact object headers افتراضية. فكل object في الـ heap يحمل header فيه بيانات عن نوعه وحالته، وهذا الـ header صار أصغر. والنتيجة أن الـ heap نفسه يتسع لعدد أكبر من الـ objects. ويظهر الفرق في استهلاك الذاكرة بوضوح في التطبيقات التي تحتوي ملايين الـ objects الصغيرة، ولا يكاد يُلاحظ في تطبيق فيه عدد قليل من الـ objects الكبيرة.
ويتضمن الإصدار أيضًا JEP 527، الذي يضيف تبادل مفاتيح هجينًا مقاومًا للحوسبة الكمية في TLS 1.3. ومن بقية القائمة: Lazy Constants في معاينة ثالثة، وPrimitive Types in Patterns في معاينة خامسة، وJFR In-Process Data Redaction، وVector API في مرحلة incubator للمرة الثانية عشرة، وPEM Encodings في معاينة ثالثة.
أما structured concurrency فما زالت في مرحلة preview، للمرة السابعة، عبر JEP 533. وذلك خلافًا لتغطيات قالت إنها صارت نهائية في هذا الإصدار. كما أن JEP 544 الخاص بالـ AOT ليس ضمن قائمة الإصدار الرسمية، رغم ذكره في بعض التغطيات.
ولأن افتراضيين تغيّرا، فالترقية هذه المرة ليست السلوك نفسه بأداء أفضل فقط. والمرجع في تقدير أثرها هو قياس الأداء قبل الترقية وبعدها على عبء العمل الفعلي لكل تطبيق.