سوف تتساءل العديد من المؤسسات المستعدة للانتقال من Oracle Java SE إلى المدة التي ستستغرقها هذه العملية. ومع ذلك، لا توجد إجابة واحدة تناسب الجميع على هذا السؤال. يعتمد الوقت اللازم للترحيل على ما لا يقل عن ستة متغيرات خاصة بالمؤسسة.
أحد هذه المتغيرات هو أهداف الترحيل الخاصة بالشركة – فبعض الأهداف يستغرق تحقيقها وقتًا أطول من غيرها. على سبيل المثال، إذا كان الهدف هو الانتقال بالكامل من Oracle Java في أسرع وقت ممكن، فستختلف خطة الترحيل عن خطة المؤسسة التي تسعى بشكل أساسي للحصول على دعم للتطبيقات القديمة تشغيل الإصدارات الأقدم من Java، مثل Java 6 و7، ويفضل اتباع نهج تدريجي على مدى فترة أطول.
التحضير للترحيل من Oracle Java SE
المرحلة الأولى من الترحيل هي أخذ مخزون Java، والذي غالبًا ما يكون الجزء الأكثر استهلاكًا للوقت في مجموعة أدوات تطوير Java (JDK) بسبب تنوع إصدارات JDK المستخدمة. عادةً، عند نشر تطبيق جديد، فإنه يستخدم أحدث إصدار من JDK في ذلك الوقت ويستمر في استخدامه حتى مع إصدار إصدارات أحدث من Java. وهذا أمر منطقي تمامًا لأنه تم اختباره باستخدام الإصدار المنشور.
بافتراض أن التطبيق يعمل بدون مشكلة، فليس هناك حاجة لتحديث إصدار JDK الخاص به. التحديث مطلوب فقط عندما لا تكون تصحيحات الأمان وإصلاحات الأخطاء متوفرة للإصدار قيد الاستخدام وتكون هناك مخاوف بشأن أداء التطبيق أو ثغرة أمنية معروفة تحتاج إلى معالجة.
لإنشاء مخزون كامل لاستخدام JDK، يجب على المؤسسات فحص كل جهاز في ملكيتها يقوم بتشغيل أي تطبيقات تعتمد على جهاز Java الظاهري (JVM). يمكن أن يكون ذلك واضحًا إذا تم استخدام أدوات إدارة أصول تكنولوجيا المعلومات (ITAM) لمراقبة استخدام البرامج. تنشر العديد من المؤسسات هذه الأدوات للتأكد من امتثالها لشروط وأحكام الترخيص. يمكن لهذه الأدوات أن تنتج بسرعة تقريرًا يوضح الأجهزة التي تم تثبيت إصدارات Java عليها. تتوفر البرامج النصية أيضًا من الموردين مثل Azul للمساعدة في جرد JVMs بسلاسة.
بعد ذلك، يجب أن تبدأ المنظمة في التفكير في المشكلات المحتملة التي قد تنشأ بناءً على ما تم العثور عليه أثناء عملية الجرد.
على سبيل المثال، من الشائع جدًا أن يقوم المستخدمون بشراء التطبيقات بدلاً من تطويرها. إن عدم الاضطرار إلى تطوير وصيانة البرامج المخصصة داخل الشركة يمكن أن يكون فعالاً للغاية من حيث التكلفة. كثير من هذا القبيل التطبيقات التي تستخدم جافا سيحدد الإصدار المطلوب من JDK وربما الحد الأدنى لمستوى تحديث الإصدار – وهذا لا يختلف عن الطريقة التي تحدد بها التطبيقات الأخرى الحد الأدنى من إصدار Windows أو Linux.
يجب على المستخدم مصدر JDK وإتاحته للتطبيق. غالبًا ما يذكر موفرو التطبيقات في وثائقهم أنهم سيدعمون التطبيق فقط إذا تم استخدامه مع JDK الصحيح. يعد هذا أمرًا معقولًا لمطور التطبيق لأنه يمكن أن يساعد في التخلص من المشكلات الناتجة عن استخدام أوقات تشغيل Java قديمة أو غير مناسبة. نظرًا لأن Oracle JDK كان منتشرًا في كل مكان في الماضي، فقد ذكر العديد من موفري التطبيقات أن Oracle JDK فقط هو الذي سيكون مؤهلاً للحصول على الدعم.
مؤخرًا التغييرات في ترخيص وتسعير Oracle JDKومع ذلك، فهذا يعني أن المستخدمين يطالبون بشكل متزايد بالدعم عند التشغيل على JDKs البديلة. سيوفر العديد من موردي التطبيقات الآن الدعم طالما أن التطبيق يعمل على إصدار معتمد من Technology Compatibility Kit (TCK) لـ OpenJDK. نظرًا لأنه يمكنهم الوثوق في أن هذه التوزيعات متطابقة وظيفيًا مع Oracle JDK، فلا داعي للقلق بشأن اختبار توزيعات متعددة باستخدام تطبيقاتهم.
في بعض الأحيان سيذكر التطبيق ذلك بالتأكيد توزيعات OpenJDK صالحة للحصول على الدعم، ولكنها ليست تلك التي تريد المنظمة استخدامها. في هذه الحالة، يجب على المستخدمين الاتصال بمورد التطبيق لإضافة التوزيع المطلوب إلى قائمتهم. وطالما تم اختباره بواسطة TCK، فلا ينبغي للمورد أن يكون لديه أي اعتراض.
في أي مؤسسة كبيرة يتم فيها استخدام تطبيقات Java متعددة، سيكون للتطبيقات مالكون مختلفون. عند التخطيط لعملية ترحيل ناجحة، من الضروري تضمين جميع الأطراف المعنية – أي جميع مالكي التطبيقات الذين يجب عليهم استخدام وقت تشغيل Java الجديد و/أو المهتمين بسلامة تطبيقاتهم.
الهجرة إلى OpenJDK
OpenJDK لا تدعم التوزيعات التصحيح الموضعي للتحديثات – يتطلب تطبيق التحديث على JDK تثبيت JDK جديدًا بالكامل. وهذا يعني أنه يمكن التعامل مع عملية تثبيت الترحيل تمامًا مثل نشر تحديث جديد، باستثناء أنها تقوم بتثبيت تحديث Zulu JDK بدلاً من تحديث Oracle JDK.
ما لم يكن هناك خطأ محدد يسبب مشكلات في استقرار التطبيق، فلن يرى المستخدمون أي حاجة ملحة للانتقال إلى إصدار جديد من Java، حتى لو كانوا يستخدمون إصدارًا قديمًا تمامًا. ومع ذلك، من وجهة نظر إدارية، من الجيد دائمًا تثبيت آخر تحديث عند الانتقال إلى توزيعة OpenJDK جديدة للحفاظ على أعلى مستوى من الأمان للتطبيقات.
في الغالبية العظمى من الحالات، تكون عملية التحديث واضحة وبدون مشاكل. ومع ذلك، في بعض الأحيان يتضمن التحديث تغييرات يمكنها تغيير سلوك التطبيق.
مثال تومكات
دعونا نلقي نظرة على مثال باستخدام ما هو شائع الاستخدام محرك أباتشي Tomcat servlet. لنفترض أن لدينا Tomcat 8 يعمل على Oracle JDK 8u202. هذا ليس أحدث إصدار من Tomcat، ولكنه يعمل بشكل مثالي مع تطبيقنا، لذلك لم تتم ترقيته. لدينا servlet قيد التشغيل يأخذ البيانات من العميل، ويقوم بإجراء استعلام في قاعدة بيانات MySQL، ويعيد النتيجة.
من أجل هجرتنانقوم بتثبيت تحديث Zulu 8 372 ونعيد تشغيل الخادم. ومع ذلك، عندما نحاول استخدام التطبيق، نحصل على رسالة خطأ تخبرنا بوجود فشل في رابط الاتصال. هذا لا علاقة له بالتحول من Oracle إلى Zulu.
بدلاً من ذلك، فهو ينتج عن تغيير تم إجراؤه في تحديث JDK 8 رقم 291 اعتبارًا من أكتوبر 2021. في هذا التحديث، تم تغيير الإعدادات الافتراضية لـ Transport Layer Security (TLS) لتعطيل TLSv1.0 وTLSv1.1 افتراضيًا. لذلك، لكي يعمل التطبيق كما كان من قبل، يجب علينا تعديل ملف jre/lib/security/java.security وإزالة مراجع TLS من إعداد خوارزميات jdk.tls.disabled.
عندما يحدث شيء من هذا القبيل، فمن المهم التحقق من أن سبب المشكلة هو استخدام تحديث مختلف لـ JDK بدلاً من توزيع مختلف. إن وجود موفر دعم تجاري يمكنه توفير التحديثات القديمة يمكن أن يكون مفيدًا للغاية في مثل هذه الحالات. ما عليك سوى تثبيت نفس مستوى التحديث لـ JDK، ثم إعادة اختبار التطبيق. في مثالنا هذا، سيتمكن فريق دعم Azul من تقديم تفاصيل تغييرات التكوين المطلوبة لحل المشكلة.
بعد تثبيت JDK الجديد، نحتاج إلى إجراء أي تغييرات مطلوبة لتبديل التطبيقات لاستخدامه. على سبيل المثال، قد يكون من الضروري تغيير متغير البيئة JAVA_HOME والمشغلات المستخدمة للتطبيقات الفردية، مثل محرك Tomcat servlet. الخيار الأكثر أمانًا هو تغيير متغير البيئة هذا على كافة الأجهزة التي تم ترحيلها.
بعد التثبيت، يجب علينا اختبار جميع التطبيقات التي تم تحويلها إلى JDK الجديد لضمان الأداء الوظيفي الصحيح. ربما لن يلاحظ المستخدمون أي سلوك مختلف ما لم تحدث تغييرات بين التحديثات.
اختبار للتحقق من السلوك الصحيح
ستختلف عملية الاختبار بشكل كبير حسب كل تطبيق. قد تحتوي التطبيقات المطورة داخليًا على اختبارات انحدار واسعة النطاق يمكنها ممارسة جميع أجزاء التطبيق بشكل كامل للتحقق من السلوك الصحيح.
قد تحتوي تطبيقات الطرف الثالث (سواء كانت مفتوحة المصدر أو تجارية) على مجموعة من الاختبارات القياسية التي يمكن تشغيلها. إذا لم يكن الأمر كذلك، فيجب على المستخدم ذو الخبرة تشغيل التطبيق وتجربة أكبر عدد ممكن من الجوانب الوظيفية.
بعد اجتياز كافة الاختبارات بما يرضي كل مستخدم، تكتمل عملية الترحيل. ستكون المنظمة الآن في وضع قوي يمكنها من الحفاظ على ملكية Java الخاصة بها إلى أعلى مستويات الأمان والاستقرار، وغالبًا ما تكون أكثر من ذي قبل. بالإضافة إلى ذلك، سيكون لديه صورة واضحة عن مكان استخدام وقت تشغيل Java والمزيد من الخبرة في ترقية الأجهزة إلى آخر تحديث لـ Java.
هذه المقالة مبنية على مقتطف من ترحيل OpenJDK للدمى، إصدار Azul الخاص، بواسطة بطل جافا سيمون ريتر.
