فئات خفية، فئات مختومة، و كتل النص ، السجلات، وEdDSA: JDK 15 لديها الكثير من القيمة.
كما يقول أحد التعبيرات المفضلة لدي ، هناك الكثير من مزايا الشوكولاتة الغنية في Java 15 . يتضمن الإصدار الجديد (الذي تم إصداره في 15 سبتمبر 2020) 14 تغييرًا مهمًا (JEPs) تهدف إلى تحسين JDK. تقدم هذه المقالة نظرة عامة سريعة على المنتجات الجديدة بناءً على المعلومات الواردة في JEP.
يمكن تقسيم 14 JEP إلى خمس مجموعات. للحصول على دراسة أكثر تفصيلاً ، راجع الوثائق الخاصة بكل منها.
وظائف جديدة ستذهلك:
- JEP 339: خوارزمية Edwards Curve Digital Signature (EdDSA)
- جيب 371: الفصول المخفية
الإضافات إلى وظائف Java SE القياسية الحالية:
- JEP 378: كتل نصية
- جيب 377: جامع نفايات ZGC
- جيب 379: شيناندواه - جامع نفايات منخفض الإيقاف المؤقت
تحسينات على وظائف Java SE القديمة:
- JEP 373: إصلاح واجهة برمجة تطبيقات DatagramSocket المهملة
نتطلع إلى منتجات جديدة:
- JEP 360: فصول مختومة (معاينة)
- JEP 375: مطابقة النمط على سبيل المثال (المعاينة الثانية)
- JEP 384: إدخالات (مسودة ثانية)
- JEP 383: واجهة برمجة تطبيقات الوصول إلى الذاكرة الخارجية (وظيفة الحاضنة الثانية)
إزالة وإنهاء الدعم:
- JEP 372: Nashorn JavaScript Engine
- JEP 374:
- JEP 381: Solaris SPARC
- JEP 385: RMI
,
خوارزمية Edwards Curve Digital Signature ( JEP 339 ). سأكون أول من يعترف بأن خوارزمية Edwards-Curve Digital Signature (EdDSA) تتجاوز معرفتي بالتشفير قليلاً. حسنًا ، لا أعرف شيئًا عنها على الإطلاق. ومع ذلك ، تم تصميم JEP هذا كمنصة تنفيذ مستقل لـ EdDSA مع أداء أفضل من تنفيذ C الحالي ، ECDSA.
وفقًا لوثائق JDK ، فإن EdDSA هو مخطط توقيع منحنى إهليلجي حديث له العديد من المزايا على تلك الموجودة في JDK.
أهداف التنفيذ:
- الغرض الرئيسي من JEP هذا هو تنفيذ مخطط التوقيع كما هو موحد في RFC 8032 . ومع ذلك ، فإن النظام الجديد لا يحل محل ECDSA.
- - EdDSA , ECDSA . , EdDSA, Curve25519 ~126 , , ECDSA, secp256r1 ~128 .
- , . .
الآن أنت تعرف أكثر مما أعرف. ترقبوا مقال مجلة Java الذي يشرح EdDSA قريبًا.
الفئات المخفية ( JEP 371 ) هي فئات لا يمكن استدعاؤها مباشرة بواسطة رمز بايت للفئات الأخرى. الغرض منها هو استخدامها من قبل الأطر التي تنشئ فئات ديناميكية في وقت التشغيل واستخدامها بشكل غير مباشر من خلال آلية انعكاس. قد تكون الفصول التي تم إنشاؤها ديناميكيًا مطلوبة فقط لفترة محدودة من الوقت ، لذا فإن الاحتفاظ بها طوال عمر فئة تم إنشاؤها بشكل ثابت يمكن أن يزيد من مساحة الذاكرة بلا داع.
الفئات التي تم إنشاؤها ديناميكيًا هي أيضًا غير قابلة للكشف. قد يكون العثور على مثل هذه الفئات بالاسم ضارًا ، لأنه يقوض الغرض منها ، وهو أنها مجرد تفاصيل تنفيذ لفئة تم إنشاؤها بشكل ثابت.
يضع إصدار الفئات المخفية الأساس للمطورين للتوقف عن استخدام واجهة برمجة التطبيقات غير القياسية sun.misc.Unsafe :: selectAnonymousClass . تعتزم أوراكل إزالة وإزالة هذه الفئة في المستقبل.
إضافات لمعايير Java SE الحالية
تم إصدار كتل النص ( JEP 378 ) التي جاءت من Project Amber أخيرًا بعد إصدارين أوليين في JDK 13 و 14. كان الغرض من إنشائها هو رغبة المطورين في تقليل صعوبة الإعلان عن واستخدام سلسلة حرفية متعددة الأسطر في Java.
تقوم كتل النص تلقائيًا بتنسيق السلاسل بطريقة يمكن التنبؤ بها ، ولكن إذا لم يكن ذلك كافيًا ، يمكن للمطور تولي التنسيق. يقدم الإصدار الثاني من الوظيفة الأولية تسلسلين جديدين للهروب للتعامل مع الأسطر والمسافات الجديدة. على سبيل المثال ، يمنع \ <line-terminator> بشكل صريح إدراج حرف سطر جديد.
في السابق ، لطباعة سطر واحد طويل من النص ، كان عليك أن تكتب مثل هذا:
باستخدام \ يجعل قراءة الكود أسهل:
يمكن أن يمنع تسلسل الهروب \ s إزالة المسافات الزائدة. وبالتالي ، فإن النص التالي يمثل ثلاثة أسطر ، كل منها يتكون من خمسة أحرف بالضبط (في السطر الأوسط ، المقابل للأخضر ، \ s غير مستخدم ، لأنه يحتوي بالفعل على خمسة أحرف).
تم تقديم جامع القمامة ZGC ( JEP 377 ) في JDK 11 كميزة تجريبية. الآن حصلت على الوضع الرسمي. ZGC عبارة عن جامع نفايات متوازي مزود بتمكين NUMA وقابل للتطوير مع زمن انتقال منخفض لجمع القمامة (أقل من 10 مللي ثانية حتى على أكوام متعددة تيرابايت) متوسط وقت الإيقاف المؤقت ، كما تم اختباره بواسطة Oracle ، أقل من 1 مللي ثانية ، والحد الأقصى أقل من 2 مللي ثانية. يقارن الشكل 1 جامع القمامة الموازي لـ Java ، G1 ، و ZGC ، مع زيادة وقت الإيقاف المؤقت لـ ZGC بمعامل 10.
الشكل 1. مقارنة أوقات التوقف المؤقت لمجمع القمامة
ومع ذلك ، بالنسبة للعديد من أحمال العمل ، قد يكون G1 (الذي لا يزال الافتراضي) أسرع قليلاً من ZGC. أيضًا ، بالنسبة للأكوام الصغيرة جدًا ، مثل تلك التي لا تزيد عن بضع مئات من الميجابايت ، يمكن أن يكون G1 أسرع أيضًا. وبالتالي ، يُنصح بإجراء الاختبارات الخاصة بك مع الأحمال الخاصة بك لمعرفة أي جامع القمامة الذي يجب استخدامه.
هام: نظرًا لأن ZGC لم يعد تجريبيًا (مضمن في بنية Oracle OpenJDK وفي Oracle JDK) ، لم تعد بحاجة إلى استخدام -XX: + UnlockExperimentalVMOptions لتنشيطه.
شيناندواه ( JEP 379) هو متغير آخر لمجمع القمامة متوفر في بعض إصدارات OpenJDK. لقد كان تجريبيًا منذ JDK 12. الآن ، كما هو الحال مع ZGC ، XX: + UnlockExperimentalVMOptions غير مطلوب.
تحديث وظائف Java SE القديمة
إعادة صياغة DatagramSocket API المتوقفة ( JEP 373 ). ضع في اعتبارك أن هذا في الأساس عبارة عن إعادة هيكلة لبعض الكود الجوراسي ، حيث يحل JEP هذا محل التطبيقات القديمة التي يصعب صيانتها لـ java.net.DatagramSocket و java.net.MulticastSocket APIs مع تطبيقات أبسط وحديثة يسهل صيانتها وتصحيحها ، والتي سوف العمل مع التدفقات الافتراضية Project Loom.
نظرًا لوجود الكثير من التعليمات البرمجية التي تستخدم واجهة برمجة التطبيقات القديمة (منذ JDK 1.0) ، فلن تتم إزالة التطبيق القديم. في الواقع ، خاصية النظام الجديدة الخاصة بـ JDK ، jdk.net.usePlainDatagramSocketImpl ، تقوم بتكوين JDK لاستخدام تطبيق مهمل إذا تسببت إعادة هيكلة API في حدوث مشكلات في اختبارات الانحدار أو في بعض الحالات.
نحن نتطلع إلى منتجات جديدة
فئات مختومة ( جيب 360 ). تم إنشاء أول نسخة مسودة في Project Amber. تقوم الطبقات والواجهات المختومة بتقييد امتدادها أو تنفيذها إلى فئات أخرى. لماذا هو مهم؟ قد يرغب المطور في إدارة التعليمات البرمجية المسؤولة عن تنفيذ فئة أو واجهة معينة. توفر الفئات المختومة طريقة تعريفية أكثر من معدلات الوصول لتقييد استخدام الطبقة الفائقة. على سبيل المثال:
الغرض من ختم الفصل هو السماح لكود العميل بمعرفة الفئات الفرعية المسموح بها. بعد كل شيء ، قد تكون هناك حالات استخدام حيث من المتوقع أن يكون التعريف الأصلي للفئة (أو الواجهة) شاملاً تمامًا ، وعندما لا يسمح المطور بتوسيعه خارج نطاق السيطرة - يمكن فقط للفئات المحددة صراحةً.
هناك بعض القيود على الفصول المختومة:
- يجب أن تكون الفئة المختومة والفئات الفرعية المسموح بها في نفس الوحدة النمطية. إذا تم الإعلان عنها في وحدة نمطية غير مسماة ، فيجب وضعها في نفس الحزمة
- يجب أن تقوم كل فئة فرعية مسموح بها بتمديد الفئة المختومة مباشرةً
- , , , — final, sealed nonsealed ( )
مطابقة النمط على سبيل المثال ( JEP 375 ). المعاينة الثانية هي تطوير آخر من Project Amber. كان الإصدار الأولي من الوظيفة في Java 14 ولا توجد تغييرات مقارنة بذلك.
الهدف هو تحسين Java من خلال مطابقة النمط لمثيل عامل التشغيل. يتيح لك ذلك التعبير بشكل أكثر دقة وأمانًا عن المنطق العام في البرنامج ، أي الاستخراج الشرطي للمكونات من الكائنات. اسمحوا لي أن أشير إلى مقالة Mal Gupta الممتازة " مطابقة الأنماط على سبيل المثال في Java 14 " كمثال.
إدخالات ( JEP 384)، مسودة ثانية. السجلات هي فئات تعمل كحاملات شفافة للبيانات غير القابلة للتغيير. تتضمن JEP الجديدة توضيحات تستند إلى تعليقات المجتمع وتدعم العديد من الأشكال الإضافية الجديدة للفئات والواجهات المحلية. تأتي الإدخالات أيضًا من Project Amber.
السجلات هي بناء موجه للكائنات يعبر عن تجميع بسيط للقيم. وبالتالي ، فهي تساعد المبرمجين على التركيز على نمذجة البيانات غير القابلة للتغيير بدلاً من السلوك القابل للتوسيع. تقوم السجلات تلقائيًا بتطبيق أساليب تعتمد على البيانات مثل المساواة والموصلين. تحافظ الإدخالات أيضًا على مبادئ Java طويلة الأمد مثل الكتابة الاسمية وتوافق الترحيل. وبعبارة أخرى ، فإنها تسهل كتابة وقراءة الفئات التي تحتوي على بيانات غير قابلة للتغيير.
الوصول إلى الذاكرة الخارجية ( JEP 383 ) هو الإصدار الثاني للحاضنة من API الذي يسمح لبرامج Java بالوصول بأمان وكفاءة إلى الذاكرة الخارجية خارج مجموعة Java. الهدف هو البدء في استبدال java.nio.ByteBuffer و sun.misc.Unsafe. إنه جزء من مشروع بنما الذي يعمل على تحسين الاتصال بين Java و APIs الأخرى.
يصف JEP بشكل مناسب الحاجة إلى هذا الابتكار على النحو التالي:
عندما يتعلق الأمر بالوصول إلى الذاكرة الخارجية ، يواجه المطورون معضلة - هل يجب عليهم اختيار مسار آمن ولكنه محدود (وربما أقل كفاءة) ، مثل ByteBuffer API ، أم ينبغي عليهم ذلك التخلي عن الضمانات الأمنية واعتماد واجهة برمجة تطبيقات غير آمنة وخطيرة وغير مدعومة؟
يقدم JEP واجهة برمجة تطبيقات آمنة وقابلة للصيانة وفعالة للوصول إلى الذاكرة الخارجية. من خلال توفير حل مستهدف لمشكلة الوصول إلى الذاكرة الخارجية ، سيتم تحرير المطورين من قيود ومخاطر واجهات برمجة التطبيقات الحالية. سيحصلون أيضًا على أداء أفضل حيث تم تصميم واجهة برمجة التطبيقات الجديدة من الألف إلى الياء مع وضع تحسينات JIT في الاعتبار.
إزالة وإنهاء الدعم
لا ينبغي أن تكون أي من هذه القرارات مثيرة للجدل.
إزالة محرك Nashorn JavaScript ( JEP 372 ). تم إهمال هذا المحرك و API و jjs في Java 11. حان الوقت لنقول وداعا.
يؤدي تعطيل وإلغاء التأمين المحجوز ( JEP 374 ) إلى إزالة تقنية التحسين القديمة المستخدمة بواسطة HotSpot JVM لتقليل النفقات العامة المرتبطة بالقفل غير المحدد. لقد أدى هذا القفل تاريخياً إلى تحسينات كبيرة في الأداء مقارنة بأساليب القفل التقليدية ، لكن مكاسب الأداء التي شوهدت في الماضي أصبحت أقل وضوحًا اليوم. انخفضت تكلفة تنفيذ التعليمات الذرية على المعالجات الحديثة.
نتج عن القفل الزائد الكثير من التعليمات البرمجية المعقدة ، وهذا التعقيد يمنع فريق تطوير Java من إجراء تغييرات مهمة على محرك المزامنة. من خلال تعطيل القفل ، وترك الأمر للمبرمج لإعادة تمكينه ، يأمل فريق تطوير Java في تحديد ما إذا كان من الحكمة إزالته بالكامل في إصدار مستقبلي.
إزالة منافذ Solaris و SPARC ( JEP 381 ). في هذه الحالة ، تتم إزالة جميع التعليمات البرمجية المصدر الخاصة بنظام التشغيل Solaris وبنية SPARC. لا يوجد شيء آخر يمكن أن أقوله.
استبعاد تنشيط RMI لإلغاء التثبيت لاحقًا ( JEP 385). يبسط Java عن طريق إزالة الجزء القديم من استدعاء الطرق البعيدة التي كانت اختيارية في Java 8.
يتم تقليل استخدام تنشيط RMI وتقليله. لا يرى فريق Java أي دليل على أن أي تطبيقات جديدة قد تمت كتابتها باستخدامه ، وهناك دليل على أن عددًا قليلاً جدًا من التطبيقات الحالية تستخدم تنشيط RMI. لم يعثر البحث في العديد من قواعد البرمجة مفتوحة المصدر على أي ذكر لأي واجهات برمجة تطبيقات مرتبطة بها. لم تكن هناك تقارير عن أخطاء تنشيط خارجية ناتجة عن RMI لعدة سنوات.
دعم تنشيط RMI كجزء من نظام Java الأساسي له تكلفة صيانة مستمرة. هذا يضيف تعقيدًا إلى RMI. يمكنك إزالة تنشيط RMI دون التأثير على باقي RMI. إزالته لا تقلل من قيمة مطور Java ، لكنها تقلل من تكاليف الصيانة طويلة المدى لـ JDK.
خاتمة
يستمر Java 15 في دورة الإصدار التي تبلغ مدتها ستة أشهر وهو إصدار متوسط الحجم مفيد لمعظم المطورين.