اليوم في الاستوديو الافتراضي لدينا هو سيباستيان داشنر. باختصار ، من هو هذا:
في هذه المقابلة سنتحدث عن المواضيع التالية:
النص المخفي- تحية معتادة: كيف أعجب به في روسيا وسيبيريا ، ركوب الدراجة JUG ؛
- ما الذي يفعله Advocates Developer وما إذا كانوا غير مستغلين؟
- أي جانب هو المصدر المفتوح لـ IBM ؛
- الحفاظ على إنتاجية المطورين (مع رابط إلى موقع Sebastian على YouTube) ؛
- الوضع الحالي حول Java EE و Jakarta EE ؛
- هل أحتاج إلى دمج Java EE و Jakarta EE؛
- الرأي حول عملية مواصفات الكسوف ؛
- حديث عن ملف تعريف IBM WebSphere Liberty Profile ، والاختلافات من Full Profile والعلاقة مع prod الحقيقي ؛
- العلاقة بمشروع Helidon وماذا عن "التخلص من Java EE وإعادة كتابته مرة أخرى" ؛
- دعم سحابة جافا: Kubernetes ، Istio ؛
- السؤال الأخير: Linux على سطح المكتب.

يتم إجراء المقابلات ، كما هو الحال دائمًا ، من قِبل Evgeny Trifonov ( phillenty ) ، و Oleg Chirukhin ( olegchir ) من مجموعة JUG.ru.
يوجين: لنبدأ بمسألة غير تقنية. على Twitter ، رأيت صورة لك في نوفوسيبيرسك في قميص من النوع الثقيل JAVA. ما هو انطباعك عن هذه الرحلة؟
سيباستيان: سعيد لأنك تعرفت على الصورة ، لدي هذا القميص من النوع الثقيل مع Joker 2017. بالتأكيد أتذكر مؤتمر JBreak. لم أكن أتخيل أبداً أنني سأذهب إلى هذه الزاوية البعيدة من سيبيريا - أعتقد من دائرة أصدقائي أنني واحد من القلائل الذين كانوا هناك. بالإضافة إلى ذلك ، في اليوم السابق للمؤتمر ، احتفلت بعيد ميلادي ، وذهبنا إلى ركوب الثلج ، وبعد ذلك جلسنا في الحمام وأكلنا الكباب. بشكل عام ، هناك العديد من الذكريات السارة. الطبيعة حول نوفوسيبيرسك جميلة جدا. وحقيقة أنه إذا عدت كراسنويارسك وتومسك ، على بعد ألف كيلومتر من حولك ، فلا توجد مدن رئيسية أخرى ، فهي مؤثرة للغاية.
يوجين: أنت محامي جافا المطور في IBM. هذا ليس موقفًا شائعًا جدًا - تميل Advocates Developer الأخرى التي أعرفها إلى الترويج لمنتجات الشركة. ما هي مسؤولياتك بالضبط في IBM؟ هل تحاول تحقيق أقصى قدر من التوزيع والاستخدام الفعال لجافا بكل طريقة ممكنة؟
سيباستيان: نعم ، هذا وصف دقيق إلى حد ما لما أقوم به. يجب أن أضيف أنه في المقام الأول أنا في مصلحة ليس الكثير من الشركة أو المنتج ، ولكن المطورين. أنا أسعى لتسهيل عملهم وتعليم الأشياء بطريقة أو بأخرى متعلقة بـ Java Enterprise. أشارك معرفتي في المدونات والبودكاست والندوات والمؤتمرات. لا أبيع أي منتجات معينة ، بل أبيع التكنولوجيا ككل.
يوجين: أنت داعم كبير للمصدر المفتوح ، لكنك تعمل لدى IBM ، وهو أمر لا يرتبط بمعظم المصادر المفتوحة لمعظم الناس. في الوقت نفسه ، أعرف أن IBM يقوم أحيانًا بدور نشط في العديد من مشاريع المصادر المفتوحة ، على سبيل المثال ، في OpenJ9. كيف تتصل IBM بالمصدر المفتوح؟
سيباستيان: لقد لاحظت بشكل صحيح أن الكثيرين غالبًا ما يستخفون بمشاركة IBM في مشاريع مفتوحة المصدر - لم يكن لدي أي فكرة عن ذلك حتى بدأت العمل في هذه الشركة. على سبيل المثال ، تقوم IBM بالكثير من العمل في Cloud Native و Java وهي أحد المساهمين الرئيسيين في Kubernetes و Istio. تم فتح الوصول إلى مصدر OpenJ9 بواسطة مؤسسة Eclipse ، والتي تم إنشاؤها بدورها بواسطة IBM. ساهمت الشركة أيضًا في تطوير تقنيات بدون خادم ، مثل Apache OpenWhisk. بشكل عام ، فإن المبرمجين في IBM ودودون للغاية بشأن المصادر المفتوحة - كل شيء تقريباً يتم القيام به في هذه الشركة الآن لديه جانب مفتوح المصدر أو مفتوح المصدر. حتى الآن ، لا يكون الأشخاص على دراية كافية بجهود IBM في هذا الاتجاه ، وعملي كمحامي مطور هو ، من بين أمور أخرى ، لإبقاء المجتمع على اطلاع.
أوليغ: قرأت مؤخرًا على Twitter أنك ذهبت في رحلة دراجة JUG خاصة في اليابان مع ستيف تشين. JUG على الدراجات النارية ، whaaaat؟ هل يمكن أن توضح هذا؟
سيباستيان: لقد كانت رحلة رائعة. لقد سافرت أنا و Stein Chin بالفعل على دراجات نارية عدة مرات ، وفي كل مرة نحاول فيها الجمع بين ذلك وبين الخطب في المؤتمرات وفي مجموعات المستخدمين. وكانت العديد من هذه الرحلات في ألمانيا وثلاث في اليابان. للوهلة الأولى ، قد يبدو أننا نقوم بذلك من أجل المتعة فقط - وبالطبع ، لا يمكننا أن ننكر أن لدينا وقتًا كبيرًا في هذه الرحلات. ولكن من وجهة نظر عملية بحتة ، تعتبر الدراجات النارية وسيلة نقل مريحة جدًا لليابان أو أوروبا الوسطى ، نظرًا لأن هناك مدن بها مجموعات مستخدمين ومجتمع تكنولوجيا معلومات على بعد مئة أو كيلومترين فقط ، ويمكنك تجنب الاختناقات المرورية على دراجة نارية. في كل من هذه الرحلات ، حاولنا مقابلة الحد الأقصى لعدد الأشخاص ومشاركة معرفتنا معهم.
أوليغ: أنت تسافر كثيرًا وذهبت إلى روسيا ، رغم أنه ليس من السهل الحصول على تأشيرتنا. هناك رأي مفاده أن المطور Advocate ليس مهنة خطيرة. كما لو كنت تسافر حول العالم ، وتستمتع بالمؤتمرات - أي شيء ، فقط لعدم كتابة الكود. هل تعتقد أن لديك عمل شاق حقيقي؟ يبدو أن الطيران كل يوم يجب أن يكون مرهقا.
سيباستيان: أعتقد أن كلا وجهات النظر صحيحة قليلاً. يعجبني عملي ، لكنه ليس بسيطًا دائمًا. واحد لا يتداخل مع الآخر. في الواقع ، يمكن أن تكون الرحلات مرهقة ، خاصة إذا كنت لا ترتاح بعد الحركة مباشرة ، ولكنك تتحدث في مؤتمر أو تنظم ندوة. وبعد المؤتمر مباشرة ، عليك ركوب الطائرة مرة أخرى ، لذا فإن اليوم كله مشغول. من ناحية أخرى ، إذا لم يتم تنفيذ هذا النشاط ، فسوف ينتقل السقف بسرعة كبيرة من هذا الإيقاع ، وسيحترق الشخص ببساطة. بشكل عام ، إذا تمكنت من تعليم الناس شيئًا ما وإجراء ندوة ناجحة في يوم واحد ، فإن التعب حتى يصبح لطيفًا.
يوجين: على حد علمي ، يتطلب هذا العمل الكثير من الجهد من أجل مواكبة أحدث التقنيات في هذا المجال. نظرًا لأعباء العمل الإضافية لـ Developer Advocates ، فإن ذلك أصعب من أولئك الذين يبرمجون باستمرار. أعلم أنك تكتب رمزًا منتظمًا لجاكرتا EE ، لذلك من الواضح أنك لم تمزق نفسك من التكنولوجيا. هل من الصعب أن تكون محامي مطور ومطور في نفس الوقت؟
سيباستيان: نعم ، بالطبع ، من المهم للغاية بالنسبة لي أن أظل مبرمجًا ، وإلا فسوف تفقد الاتصال بالواقع. للحديث عن التكنولوجيا بكفاءة ، فأنت بحاجة إلى خبرة مستمرة في العمل معها. ووقت البرمجة هو حقا أقل بكثير بسبب المؤتمرات. بالإضافة إلى ذلك ، يجب أن تكون مفتونًا بالجانب التقني للأشياء وستكون مستعدًا لقضاء الأمسيات وعطلات نهاية الأسبوع على ذلك. بشكل عام ، هناك حاجة إلى توازن معين بين جانبي النشاط.
أوليغ: دعنا ننتقل إلى المشكلات الفنية. يوجد رسم على الصفحة الأولى من مدونتك:
يجب أن تكون بسيطة ومثمرة.
يجب أن يحل تكنولوجيا المعلومات المشاكل وليس خلقها.
أعتقد أن تكنولوجيا المعلومات فرصة وليست عامل تكلفة.
ما هي في رأيك أهم العوامل التي تحدد إنتاجية مطور جافا؟ هل هناك أي نصائح حول كيفية أن تكون أكثر إنتاجية ، الخارقة الحياة ، nishtyaki التقنية المحددة والمرافق مثل jcmd أو sdkman ، أي شيء؟
سيباستيان: نعم ، هناك العديد من هذه البرامج. بالنسبة للبساطة ، فإننا نتحدث عن الحاجة إلى السعي للتخلص من التعقيد المفرط في كل من الأدوات التي نطورها وفي التطبيقات التي نستخدم فيها هذه الأدوات. غالبًا ما يتم جذب المطورين بالتعقيد في حد ذاته ، حيث يتم إضافة المزيد والمزيد من الميزات إلى المنتج فقط بسبب الاهتمام بالرياضة. تحتاج دائمًا إلى أن تسأل نفسك: هل سيصبح العالم أفضل من هذه الميزة؟ هل سيساعد على حل أي مشكلة؟ هل ستقربنا من استكمال المنتج؟
إذا تحدثنا عن إنتاجية المطور نفسه ، فيمكنني حقًا التوصية بموارد لذلك. جوجل اسمي وعبارة "إنتاجية المطور". لقد سجلت دورة فيديو ، والتي يتم نشرها على يوتيوب ، وهناك أقدم المشورة بشأن هذا الموضوع. يتحدث عن استخدام سطر الأوامر والمفاتيح الساخنة وكيفية استخدام لوحة المفاتيح. النقطة العامة هي كيفية القيام بالمزيد من العمل في وقت أقل. وإذا بدأت الخوض في هذا الموضوع ، فسيتم تأخير عملية التشغيل الآلي وتحسين العمل. ستحصل على مزيد من الوقت للتفكير في حل المشكلة وأقل غباءً على المفاتيح. بشكل عام ، أداء البرمجة موضوع قريب جدًا مني.
أوليغ: بقدر ما أفهم ، أنت مسؤول في MicroProfile ، وبالتالي يمكنك معرفة كل ما يتعلق به. الرجاء إخبارنا بما يحدث حول Java EE وجاكرتا؟ قرأت عنها قليلاً ، لكن بالنسبة لي ، كشخص من عالم الربيع ، كل هذا محير للغاية.
سيباستيان: كما تعلمون ، جاكرتا EE هي خليفة Java EE ، التي يتم نقلها الآن إلى Eclipse Foundation. هذه عملية معقدة إلى حد ما ، ولم تكتمل بعد ، لذلك لا يمكن للمطورين استخدام Jakarta EE حتى الآن. ومع ذلك ، فإن الأساس لا يزال يعتمد على معايير Java EE ، وستكون نقطة الانطلاق Java EE 8. بالطبع ، في المستقبل ، ستواصل جاكرتا EE التطور بنفس الطريقة التي تطورت بها Java EE من خلال JCP (Java Community Process). هذا يعني أن مجتمعًا يضم العديد من الشركات والشركات والمطورين الفرديين سيطور معًا معايير الإصدار الجديد من Java.
بسبب هذه التغييرات في Java EE ، ظهرت MicroProfile. تم إنشاؤه بواسطة العديد من البائعين الذين يقومون بتشغيل خوادم Java EE. الهدف هنا هو ضمان تطوير أسرع للتكنولوجيا ، وأقل ارتباطًا بالمعايير الصارمة. يبدو مثيرا للاهتمام بالنسبة لي أن برنامج MicroProfile يحاول تعويض أوجه القصور في Java EE فيما يتعلق بالخدمات الميكروية الحديثة السحابية. على سبيل المثال ، ليس لدى Java EE بعد أنظمة للتكوين عن طريق الحقن وتحمل الأعطال والمراقبة وجميع أنواع OpenTracing وما شابه. يتيح لك MicroProfile الوصول إلى كل هذه الأشياء ، لذلك لا تحتاج إلى تنفيذها جميعًا بنفسك. علاوة على ذلك ، في جميع الحالات تقريبًا ، يتم احترام التوافق مع Java EE. تعتبر معايير Java EE (مثل JAX-RS و CDI) ، والتي يعرفها معظم مطوري JavaEE بالفعل ، أساسًا. لذلك ، عندما أجد تسامحًا مع الأخطاء في تطبيق Java EE الخاص بي ، على سبيل المثال ، لا أكتب كل هذا يدويًا ، ولكن أدمج MicroProfile مع طلبي. هذان النظامان الإيكولوجيان يمتزجان جيداً معًا. بالنسبة للعديد من التطبيقات ، مثل Open Liberty أو Payara ، تدعم أوقات التشغيل كلاً من MicroProfile و Java EE. كل ما تبقى يجب القيام به في هذه الحالة هو تضمين ميزات معينة في وقت التشغيل ، ثم إضافة مشاريع MicroProfile اللازمة إلى تطبيق Java EE. بينما ننتظر الانتقال النهائي لـ Java EE إلى Eclipse Foundation ، يمكنك استخدام هذا الحل.
أوليغ: هل تعتقد أنه ينبغي جعل MicroProfile جزءًا من جاكرتا؟
سيباستيان: هذا سؤال عظيم ، وليس هناك قرار نهائي بشأنه بعد. شخصيا ، أعتقد أن MicroProfile يعمل بشكل أفضل كنوع من حاضنة جاكرتا EE. تتم إضافة المعيار الجديد أولاً إلى MicroProfile (كما حدث مع OpenTracing أو التكوين عن طريق الحقن) ، ثم ننظر إلى كيفية تصرف النظام في الإنتاج. عندما تصل إلى مرحلة النضج ، فإن عناصرها التي أثبتت أنها أصبحت معايير كاملة. وبالتالي ، نتخلص من بعض عدم اليقين ، لأننا نعرف بالفعل ما إذا كان النظام يعمل بشكل جيد في الإنتاج أم لا.
أوليغ: بما أننا كنا نتحدث عن المعايير ، فقد رأيت عمليات مواصفات Eclipse ، لقد كانت googlodok ضخمة ، وكان من الصعب للغاية فهمها. تبدو المستندات ذات مواصفات مشروع جاكرتا EE تشابهاً جهنمياً. هل يمكن أن تساعد هذه الكرة على الاسترخاء؟ على سبيل المثال ، كيف يختلف هذا عن عملية مجتمع Java؟
سيباستيان: مؤسسة إكليبس هي مؤسسة مفتوحة المصدر. في الوقت الحالي ، نحاول تحديد شكل تلك العمليات وفقًا لتطور جاكرتا EE في المستقبل. لقد ذكرت JCP - لذلك ، أنا أتفق تمامًا مع الرأي القائل بأن معايير جاكارتا EE يجب أن تصاغ على JCP. أعتقد أن هذا النموذج أظهر نفسه بشكل جيد للغاية. يجب أن يؤخذ في الاعتبار أنه لا توجد شركة تحتكر تطوير معايير لجاكرتا EE. تشارك في هذه العملية العديد من الشركات التي لديها نفس الحقوق أكثر أو أقل ، بحيث لن يكون عالقًا في التطوير إذا لم يعد بإمكان أي منها المشاركة فيها. أعتقد أن هذه ميزة مهمة ، لأن هذه التكنولوجيا مهمة جدًا ، وهي أكثر أمانًا للتطوير في مجتمع مفتوح.
أوليغ: هذه التكنولوجيا المتطورة تحتاج إلى اختبار على شيء ما. هل تستخدم مجموعات توافق التكنولوجيا لجافا وجاكرتا؟ أو هل لديك جناح الاختبار الخاص بك؟
سيباستيان: هذا أيضًا موضوع مهم للغاية. في JCP ، كل هذه TCK عادة ما يكون لها مصدر مغلق. وكانت هذه ميزة مشكوك فيها جدا. من ناحية ، يمكن أن توفر المواصفات الاختبارات التي تظهر ما إذا كان بعض التنفيذ صحيحًا أم لا. لكن المطور العادي لم يكن يعرف بالضبط ما الذي تم اختباره في الداخل ، وما هي تغطية هذه الاختبارات ، إلخ. الآن أصبحت TCK مفتوحة المصدر. يمكن الآن لجميع الشركات والمطورين المشاركة في تطويرها وتحسينها. إذا اتضح أن منتج الشركة لا يعمل كما هو موضح في المواصفات ، فلا يمكنك الإشارة إلى هذه الشركة فقط ، ولكن يمكنك أيضًا ترك طلب في TCK نفسه. أو حتى أفضل من ذلك ، يمكنك إرسال بعض طلبات السحب وتحسين TCK نفسه. لذا ، فأنت لا تقوم بتحسين البرنامج الخاص بمورد واحد فقط ، ولكن أيضًا تحسين النظام البيئي بأكمله.
Oleg: يوجد منتج آخر له كلمة "Profile" باسمه: ملف تعريف IBM WebSphere Liberty. نظرًا لأنك تعمل في IBM ، هل يمكنك إخبارنا بما هو وما الفرق بين Open Liberty؟
سيباستيان: WebSphere Liberty Profile هو نسخة تجارية من Open Liberty. هذا هو خادم تطبيق Java EE الذي توفر IBM الدعم التجاري له. قد أكون مخطئًا ، ولكن ، في رأيي ، أصبحت Open Liberty مفتوحة المصدر قبل عام ونصف. بفضل هذا ، أصبح لدى مطوري المؤسسات الآن خادم تطبيقات مجاني ومختبر من حيث الإنتاج. إذا كانت الشركة تحتاج إلى دعم تجاري أو بعض الميزات التجارية ، فيمكنها استخدام WebSphere Liberty Profile. إنه عام 2019 ، وأعتقد أنه يجب على كل شركة الآن توفير إصدار مفتوح المصدر من منتجها حتى تتاح للمطورين الفرصة لتجربة المنتج مجانًا. يعد OpenSource مهمًا للغاية ، وأنا سعيد لأن لدى IBM الآن العديد من الخيارات لخادم WebSphere Liberty Server السابق.
أوليغ: سمعت أنه مكتوب على رأس OSGi. هل يمكن أن تخبرنا المزيد عن كيفية ترتيبها في الداخل؟
سيباستيان: أنا شخصياً لم أقم بتطوير Open Liberty ، لكن على حد علمي ، فإنه يقع حقًا تحت OSGi. من المثير للاهتمام أنه يمكنك ببساطة تكوين الميزات التي سيتم تضمينها. إذا كنت تريد استخدام MicroProfile فقط ، والذي يغطي عددًا صغيرًا فقط من معايير Java EE ، فيمكنك تكوين النظام وفقًا لذلك. أو يمكنك إجراء ذلك حتى يكون لديك تطبيق Java EE كامل. نظرًا لحقيقة أن ما هو مطلوب حقًا فقط يتم تضمينه في مثيل قيد التشغيل ، يتم تحقيق وقت بدء التشغيل الأمثل واستهلاك الحد الأدنى من الموارد.
أوليغ: هل يختلف تكوين واستخدام Liberty Profile عن ملف التعريف الكامل؟ هل تستخدم نفس الأدوات في كلتا الحالتين؟
سيباستيان: لا توجد اختلافات كبيرة في الاستخدام. فيما يتعلق باختيار الميزات ، يمكن تكوين كلا الخادمين على قدم المساواة. إذا كان لديك تطبيق Java EE أو MicroProfile ، فسيكون الإعداد هو نفسه بالنسبة لكلا النوعين.
أوليغ: تستخدم الشركات الملف الكامل منذ فترة طويلة. كيف مبرر استخدام Liberty Profile في المؤسسات الكبيرة؟
سيباستيان: لها ما يبررها على الإطلاق. حتى إذا اشترت الشركة دعمًا تجاريًا ، فإن هذا لا يعني أنه يجب عليها استخدام "الملف الشخصي الكامل" ، فمن المعقول تمامًا استخدام إصدار أخف. إذا كان منتج الشركة مبني على خدمات ميكروية حديثة وأوقات تشغيل خفيفة ، فقد يكون من الأفضل لهم اختيار WebSphere Liberty وتكوينه بحيث يعمل ، على سبيل المثال ، فقط مع MicroProfile. لحسن الحظ ، فإن الدعم التجاري والميزات التجارية لا علاقة لهما بالعالم القديم في WebSphere ، لذلك وقت التشغيل نفسه خفيف وصغير بشكل مدهش ، يبدأ التشغيل بسرعة كبيرة ويمكن نشره في ثوانٍ. لذلك إذا كان لديك تطبيق حديث يستند إلى Java EE ، فيمكنك تكوين ميزاتك وفقًا لذلك وتضمين المعايير المطلوبة فقط. بغض النظر عما إذا كنت تستخدم ميزات تجارية ، فلا يزال بإمكانك الوصول إلى وقت التشغيل السريع والحديث هذا.
أوليغ: في أكتوبر ، أصدرت شركة أوراكل هيليدون ، وهو إطار خدمات ميكروية خفيف الوزن في جاوة. حسب علمي ، لا يستخدم أيًا من خوادم التطبيقات الحالية ، فهو مبني على مجموعة المكتبات الخاصة به. وهي توفر معًا الأساس لإنشاء خدمات microservices - ميزات التكوين وإعدادات الأمان ورفع خادم الويب وما إلى ذلك. على رأس هذا النظام ، تم تطبيق MicroProfile. لدي انطباع بأن مطوري Helidon يعتقدون أن Java EE لديه الكثير من الإرث ويجب التخلص منه وإعادة كتابته. ما رأيك في هذا؟
سيباستيان: Helidon هو مشروع مثير جدا للاهتمام. ولكن بصراحة ، يبدو من السذاجة بالنسبة لي أن أعتقد أن Java EE بحاجة إلى إعادة كتابتها بالكامل. في الواقع ، لا تحتاج معظم التطبيقات إلى Java EE ككل. كقاعدة عامة ، مطلوب مجموعة مخصصة من الميزات / المعايير ، وغالبا ما تستخدم في تطبيقات المؤسسة. على سبيل المثال ، لا يوفر MicroProfile العادي بعد JPA أو البرامج النصية المعقدة للتعدد. هذا يتطلب على الأقل بعض مكونات Java EE. بشكل عام ، أرى الآن عملية إنشاء تطبيق بهذه الطريقة. استنادًا إلى أهم مكونات Java EE ، على سبيل المثال ، CDI و JPA و JAX-RS و JTA وما إلى ذلك ، نختار مجموعة المعايير التي نحتاجها ، مع تجاهل العديد من الأشياء الموروثة الموجودة في Java EE. بناءً على هذا الاختيار ، نأخذ وقت التشغيل الذي يدعم جميع هذه الميزات. إذا كنا نفعل أي شيء يتعلق بالخدمات الميكروية المحلية السحابية ، فإننا نضيف معايير MicroProfile ، على سبيل المثال ، التسامح مع الخطأ. لكن وقت التشغيل مثل Helidon لا يدعم الميزات التي تنتمي فقط إلى Java EE ، وفي الوقت نفسه ، فإن تعدد مؤشرات الترابط أو JPA من الميزات التي ، في تجربتي ، ضرورية للغاية. أفضل وقت تشغيل يدعم كلاً من Java EE / Jakarta EE و Microprofile ، وفي الوقت نفسه يمنح الفرصة لاختيار الميزات المطلوبة لتطبيق معين. على سبيل المثال ، إذا كنت بحاجة إلى المثابرة ولديك قاعدة بيانات ، فيمكنك تمكين JPA. بشكل عام ، سيكون لديك مجموعة ميزات تشبه إلى حد كبير MicroProfile ، ولكن سيكون من الضروري أيضًا إجراء شيء من Java EE. هذه الأنواع من أوقات التشغيل هي Open Liberty و Payara و WildFly وهلم جرا.
أوليغ: على حد علمي ، فإن إحدى الميزات الأكثر إثارة للاهتمام التي سيتم تنفيذها في جاكرتا في المستقبل القريب هي دعم التقنيات السحابية الحديثة. ماذا عن جافا في الحاويات الآن؟ بقدر ما أتذكر ، قبل عدة سنوات على OpenJDK bug tracker ، كان هناك العديد من الأخطاء المتعلقة بالتوافق ، وحجم الكومة ، والإشارات ، وهلم جرا. هل من الممكن استخدام Java في الحاويات الآن ، في 2019؟
سيباستيان: نعم بالتأكيد. لم يكن السبب وراء معظم المشكلات المرتبطة بهذا هو جافا نفسها ، ولكن الطريقة التي تعامل بها Linux مع الحاويات. في كثير من الأحيان الحاوية ببساطة لم تكن تعرف عن القيود المفروضة على الموارد المختلفة التي يمكن وضعها. في الإصدارات الأخيرة ، تم حل هذه المشاكل. يمكنك الآن تشغيل Java في الحاوية ، وسيتم تمكين هذه الخيارات افتراضيًا. وإذا طلبت حجم الذاكرة في النظام أو حجم كومة الذاكرة المؤقتة الافتراضية ، فسيتم تحديد هذه القيم بشكل صحيح. تعمل Java EE بشكل رائع في حاويات Docker ، وبشكل عام ، تتكامل بشكل جيد مع التقنيات السحابية الأصلية.
أوليغ: ماذا عن البنية التحتية؟ هل تستخدم شيئا مثل Kubernetes أو Istio؟
سيباستيان: نعم ، نشيط للغاية. Docker, Kubernetes, — Istio. Java EE. Cloud-native , , , — , , , ..
: Java EE Kubernetes ? API ?
: Kubernetes Istio . cloud-native . . , Docker, Kubernetes. , - URL, . Kubernetes DNS Istio. . , — -, .
: Java ?
: — Java , . , enterprise- — MicroProfile, cloud-native (Istio, Kubernetes). MicroProfile , . , .
: JPoint « Java Enterprise». ?
: , enterprise-, . — - ; — . Java EE-, , , , .
JPoint. , — . Java-, — .
: . (, «» ). Linux, : ?
: . Linux , , , , . , , . , , . , , . Arch Linux — , . Linux . Ubuntu UI, . — Linux , , , . , , , .
أوليغ: شكرًا جزيلاً على الإجابات!
قريبًا ، من 5 إلى 6 أبريل ، سيقدم سيباستيان عرضًا تقديميًا في موسكو في JPoint مع تقرير "تطبيقات Java Enterprise المقاومة للرصاص من أجل حياة الإنتاج القاسي" . إلى جانبه ، سيأتي سيمون ريتر وكوهسوكي كاواجوتشي وأندريه بانجين وغيرهم. هنا يمكنك أن تجد البرنامج.
على الأول من مارس تكلفة تذاكر سيزداد.