قصة Java من Sun إلى Oracle، وكيف بقيت مفتوحة

في مقال قصص لغات البرمجة ومن صنعها رأينا كيف بدأت Java مشروعاً سرياً في Sun سنة 1991 لجهاز اسمه *7 لم يصل إلى السوق، وكيف تحولت اللغة إلى الإنترنت وأعلن عنها في مايو 1995، ولن نعيد تلك البداية هنا. هذا المقال يبدأ من حيث انتهت تلك القصة، فيحكي ما حدث لـ Java بعد أن خرجت إلى العالم: كيف وعدت Sun بأن تكتب الكود مرة واحدة وتشغله في كل مكان، ولماذا فتحت كودها بعد عشر سنوات، وماذا تغير عندما اشترتها Oracle، وكيف انتهت أشهر قضية برمجية في المحاكم الأمريكية، ثم كيف تحولت Java من لغة تتأخر إصداراتها سنوات إلى لغة تصدر نسخة جديدة كل ستة أشهر بالضبط.

وقصة Java من أجمل قصص التقنية لسبب واضح، وهو أنها مرت بكل ما يمكن أن يمر به مشروع برمجي كبير: شركة تخترع وتنفتح ثم تضعف وتباع، وشركة تشتري وتقاضي وتغير الرخص، ومجتمع ينقسم ويتفرع ثم يعود ليبني، ومع ذلك بقيت اللغة نفسها مستقرة إلى درجة أن برنامجاً كتب قبل عشرين سنة ما زال يعمل في الغالب على الإصدار الحالي.

وسوف نناقش في هذا المقال ما يلي:

• سنوات Sun بعد 1995: وعد «اكتب مرة وشغل في كل مكان»، وصعود ال Applets وسقوطها، وJava للمؤسسات، وعملية JCP.
• لماذا فتحت Sun كود Java في 2006 تحت اسم OpenJDK، وما معنى استثناء Classpath.
• شراء Oracle لشركة Sun في 2010، ومن غادر، والمشاريع التي انفصلت عنها.
• قضية Google وOracle من 2010 إلى حكم المحكمة العليا في 5 أبريل 2021، وما الذي قررته المحكمة بالضبط.
• انتقال Java EE إلى مؤسسة Eclipse باختصار.
• انتظار Java 9 الطويل، ثم قطار الإصدارات كل ستة أشهر، وجدول بكل إصدار منذ Java 7 وأهم ما فيه.
• من يكتب كود Java اليوم، وما الأرقام المتاحة عن ذلك.

وإذا كان سؤالك العملي هو «هل Java مجانية، وأي نسخة نستخدم في الشركة؟» فقد خصصنا له مقالاً مستقلاً بتجربة عملية هو هل Java مجانية؟ أي JDK تستخدم في شركتك، أما هنا فالتركيز على القصة وكيف وصلت Java إلى وضعها الحالي.

والصورة التالية تبين المحطات الرئيسية التي سوف نمر عليها في هذا المقال:

سنوات Sun: اكتب مرة واحدة وشغل في كل مكان

في 23 يناير 1996 أعلنت JavaSoft، وهي الوحدة التي أنشأتها Sun لـ Java، صدور Java 1.0 للتنزيل المجاني على Windows 95 وNT وعلى Solaris، مع أداة Applet Viewer لتشغيل وتجربة ال Applets، وهي برامج صغيرة تنزل مع صفحة الويب وتعمل داخل المتصفح. والفكرة التي باعت بها Sun اللغة لسنوات هي ما سمته وعد «اكتب مرة واحدة وشغل في كل مكان» Write Once, Run Anywhere، واختصاراً WORA، وقد بقيت Sun تذكر هذا الوعد بالاسم حتى في إعلانها سنة 2007.

والسبب في أن هذا الوعد كان ممكناً هو أن مترجم Java لا ينتج كود آلة لمعالج معين، وإنما ينتج bytecode تنفذه الآلة الافتراضية JVM، فكل ما تحتاجه لتشغيل البرنامج على نظام جديد هو JVM لهذا النظام، وقد شرحنا خطوة الترجمة هذه بالتفصيل في مقال أدوات البناء Build Tools.

صعود ال Applets وسقوطها

كانت ال Applets هي الواجهة التي عرف بها أغلب الناس Java في التسعينات، فهي تسمح بتشغيل برنامج تفاعلي داخل صفحة ويب في زمن كانت فيه الصفحات نصوصاً وصوراً ثابتة. ولكنها كانت تحتاج إلى إضافة Plug-in في المتصفح، والمشاكل الأمنية المتعلقة بالمتصفح كانت كبيرة إلى درجة أن صفحة JDK 8 تذكرها سبباً لتأخير الإصدار كما سيأتي، ثم بدأت المتصفحات نفسها تتخلى عن نظام الإضافات كله. والقصة الرسمية للنهاية مكتوبة في وثائق OpenJDK على ثلاث مراحل:

• JEP 289 في Java 9 جعل واجهة Applet مهملة Deprecated، والسبب المكتوب في الوثيقة أن أغلب المتصفحات حتى أواخر 2015 كانت قد أزالت دعم الإضافات أو أعلنت موعداً لإزالته.
• بحسب خطة دعم Oracle لم تعد Java 11 وما بعدها تحتوي على إضافة المتصفح وJava Web Start أصلاً، وبقيت Java 8 هي آخر إصدار يحملها.
• JEP 398 في Java 17 جعلها مهملة تمهيداً للحذف، ثم حذفت فعلاً في Java 26 مع JEP 504، الذي يقول إنها لم تعد مفيدة لأن الإصدارات الحديثة من JDK والمتصفحات لا تدعم ال Applets.

ولاحظ أن Java لم تسقط مع ال Applets، والسبب أن مركز الثقل كان قد انتقل في تلك السنوات من المتصفح إلى السيرفر.

Java في السيرفر: J2EE ثم Java EE

على السيرفر وجدت Java مكانها الحقيقي، فأصدرت Sun مجموعة مواصفات للتطبيقات الكبيرة سمتها J2EE ثم Java EE، وفيها Servlet لاستقبال طلبات HTTP وJPA لقواعد البيانات وغيرها، وبنيت عليها سيرفرات تطبيقات Application Servers تبيعها شركات كثيرة. وهذا الجزء من القصة له نهاية مختلفة سوف نراها بعد قليل، عندما خرجت Java EE من Oracle إلى مؤسسة Eclipse.

عملية JCP: من يقرر ما هي Java؟

عندما يكون للغة أكثر من شركة تبني منها نسخاً، يظهر السؤال: من يقرر ما هي Java الصحيحة؟ وكانت إجابة Sun هي عملية مجتمع Java، أي Java Community Process واختصاراً JCP، التي تقول صفحتها الرسمية إنها تأسست في 8 ديسمبر 1998. وفي هذه العملية يمر كل تغيير في المواصفة عبر طلب يسمى JSR، أي Java Specification Request، وتصوت عليه لجنة تنفيذية Executive Committee تضم شركات وأفراداً ومجموعات مستخدمين. وقد شرحنا كيف تعرف Java اليوم عبر المواصفة وJSR والتطبيق المرجعي في قسم Java في مقال مواصفات لغات البرمجة، والذي يهمنا هنا أن هذه اللجنة كان لها صوت حقيقي، وسوف نرى أنها رفضت في 2017 مواصفة كانت Oracle نفسها تقودها.

لماذا فتحت Sun كود Java؟

كانت Java في سنواتها الأولى مجانية التنزيل، ولكن كودها لم يكن مفتوحاً برخصة حرة، وهذا الفرق بين المجاني والحر شرحناه في مقال ما هي البرمجيات مفتوحة المصدر. وكانت النتيجة أن توزيعات Linux لم تستطع أن تضع Java الأصلية في مستودعاتها الحرة، وأن مجتمع البرمجيات الحرة بنى بدائل خاصة به مثل GNU Classpath، وأن ريتشارد ستولمان Richard Stallman كان يسمي الاعتماد على Java وقتها «فخ Java» Java Trap.

وفي 13 نوفمبر 2006 تغير ذلك، فقد أعلنت Sun في صفحة بعنوان Sun Opens Java أنها تفتح كود تطبيقاتها الثلاثة Java SE وJava ME وJava EE برخصة GPLv2، وكتبت أنها «نفس رخصة GNU/Linux»، والسبب الذي ذكرته Sun في الإعلان نفسه هو أنها تؤمن ببناء المجتمعات ومشاركة التقنيات لتشجيع مشاركة أوسع. وفي 8 مايو 2007 أعلنت Sun اكتمال الوعد بنشر JDK كامل قابل للبناء في مشروع OpenJDK، وفي الإعلان ثلاث تفاصيل مهمة:

• بقيت أجزاء قليلة من الكود لم تستطع Sun فتحها لأنها مملوكة لأطراف أخرى Encumbered Code، فنشرتها كملفات ثنائية Binary Plugs إلى أن يكتب المجتمع بديلاً حراً لها، وهذا ما قصده ستولمان في تعليقه داخل الإعلان عندما شكر Sun وقال إن آخر عائق أمام التخلص من «فخ Java» هو هذا الكود غير الحر.
• أعلنت Sun مجلس حوكمة مؤقت Interim Governance Board من خمسة أعضاء، مهمته كتابة دستور لمجتمع OpenJDK خلال سنة.
• أصبح بإمكان أي نسخة مبنية من OpenJDK أن تختبر توافقها مع مواصفة Java SE 6 بحزمة اختبارات التوافق TCK، وأن تحمل شعار «Java Compatible» إذا نجحت.

والنتيجة العملية ظهرت بسرعة، فصفحة مشروع OpenJDK 6 تذكر أن نسخاً مبنية من كوده نجحت في اختبارات TCK، ومنها حزم Fedora 9 وUbuntu 9.04، أي أن Java دخلت مستودعات توزيعات Linux الحرة لأول مرة.

ما معنى استثناء Classpath؟

وقد يتساءل البعض: إذا كانت Java برخصة GPL، فهل يجب أن يكون كل برنامج يعمل عليها برخصة GPL أيضاً؟ والإجابة لا، والسبب هو الاستثناء الذي أضيف إلى الرخصة. فرخصة GPL تعتبر البرنامج الذي يربط Link بمكتبة GPL عملاً واحداً مشتقاً منها، ولو طبقت هذه القاعدة على Java لأصبح كل تطبيق Java مجبراً على أن يكون مفتوحاً. لذلك تحمل ملفات المكتبة نصاً يسمى استثناء Classpath Classpath Exception، يعطيك فيه أصحاب الحقوق إذناً بأن تربط المكتبة بوحدات مستقلة Independent Modules وتنتج منها برنامجاً تنفيذياً وتوزعه بأي رخصة تختارها لتلك الوحدات. وبهذا الشكل يبقى كود JDK نفسه حراً، وأي تعديل عليه يبقى تحت GPL، أما تطبيقك الذي يعمل عليه فهو ملكك وبالرخصة التي تريدها، وهذه هي الرخصة التي تسمعها اليوم باسم GPLv2+CE أو GPLv2 with Classpath Exception.

Oracle تشتري Sun

في 27 يناير 2010 أعلنت Oracle أنها أكملت شراء Sun Microsystems، فانتقلت معها Java وMySQL وOpenOffice.org وSolaris وغيرها إلى شركة تختلف ثقافتها كثيراً عن Sun. وأول أثر ظهر على Java كان في الخطط، فقد كان JDK 7 متأخراً، فكتب Mark Reinhold، كبير معماريي منصة Java في Oracle، في سبتمبر 2010 أن الخطة المعتمدة أصبحت الخطة B Plan B: إصدار JDK 7 في منتصف 2011 دون Lambda وJigsaw وجزء من Project Coin، وتأجيل هذه الميزات إلى JDK 8. وتؤكد صفحة JDK 7 أن الإصدار أعيد تخطيطه بعد شراء Oracle لـ Sun بحسب هذه الخطة، وأنه صدر في 28 يوليو 2011.

ومع الشراء غادر عدد من الأسماء المعروفة، وأشهرهم جيمس جوسلينج James Gosling نفسه، الذي كتب في مدونته في 9 أبريل 2010 أنه استقال من Oracle في 2 أبريل، وأنه يصعب عليه أن يشرح السبب لأن أي شيء دقيق وصادق يقوله «سيضر أكثر مما ينفع».

وفي السنوات القليلة بعد الشراء خرجت من مشاريع Sun السابقة ثلاث نسخ بديلة Forks مشهورة، وكل واحدة منها لها قصتها الخاصة على الموقع أو في مصادرها:

• MySQL وMariaDB: بدأ Michael Widenius، أحد مؤسسي MySQL، نسخة MariaDB بعد أن أصبحت MySQL في طريقها إلى Oracle، وقد حكينا القصة في قسم من أين جاء MariaDB؟.
• OpenOffice وLibreOffice: في سبتمبر 2010 أعلن عدد من المساهمين القدامى مؤسسة The Document Foundation وخرج LibreOffice من OpenOffice.org، وقد ذكرناها مثالاً في قسم النسخة البديلة Fork في مقال الحوكمة.
• Hudson وJenkins: أداة التكامل المستمر Continuous Integration التي بدأت في Sun باسم Hudson، اختلف مجتمعها مع Oracle على إدارة المشروع واسمه، وفي 29 يناير 2011 أعلن المجتمع نتيجة التصويت: 214 صوتاً لتغيير الاسم و14 للبقاء، فولد Jenkins الذي تعرفه اليوم، وكتب في الإعلان أن Jenkins ليس مشروع Oracle ولا مشروع أي شركة وإنما مشروع المجتمع.

ولاحظ أن Java نفسها لم يخرج منها Fork منفصل بحجم MariaDB أو LibreOffice، والسبب في رأينا أن الكود كان قد فتح قبل الشراء برخصة GPL، فبقيت شركات مثل IBM وRed Hat تعمل داخل OpenJDK بدل أن تبني نسخة منفصلة، وهذا مثال عملي على ما شرحناه في مقال الحوكمة من أن الرخصة المفتوحة هي الضمان الأخير بيد المجتمع.

قضية Google وOracle: هل يمكن أن تملك واجهة برمجية API؟

هذه القضية هي الأشهر في تاريخ البرمجيات أمام المحاكم، وسوف نحكيها هنا من نص حكم المحكمة العليا الأمريكية نفسه، وليس من الأخبار التي كتبت عنها.

تقول المحكمة إن Google اشترت Android في 2005، وأرادت أن تبني منصة للأجهزة المحمولة يستطيع ملايين المبرمجين الذين يعرفون Java أن يكتبوا لها مباشرة، فكتبت Google كود التنفيذ Implementing Code الخاص بها، ولكنها نسخت في 37 حزمة Package كود التعريف Declaring Code من واجهة Java SE البرمجية، أي أسماء الدوال والكلاسات وطريقة تنظيمها في حزم، وهي تقريباً 11,500 سطر. وفي 2010 اشترت Oracle شركة Sun، و«بعد ذلك بقليل» كما يقول الحكم رفعت دعوى على Google أمام المحكمة الفيدرالية في شمال كاليفورنيا.

ولكي تفهم الفرق بين النوعين من الكود، انظر إلى السطر التالي من واجهة Java:

public static int max(int a, int b)

هذا السطر هو كود التعريف، أي الاسم والمعاملات التي يحفظها المبرمج ويكتبها في كوده، أما الأسطر التي تقارن بين الرقمين وترجع الأكبر فهي كود التنفيذ. وGoogle نسخت النوع الأول وكتبت الثاني بنفسها، والسؤال أمام المحاكم كان: هل يحمي قانون حق المؤلف Copyright النوع الأول، وإذا كان يحميه فهل استخدام Google له «استخدام عادل» Fair Use مسموح؟

والصورة التالية تبين المحطات التي مرت بها القضية كما يرويها الحكم:

في الصورة أعلاه لاحظ التالي:

• في المحاكمة الأولى رفضت هيئة المحلفين ادعاءات Oracle المتعلقة ببراءات الاختراع Patents، ولم تتفق على مسألة الاستخدام العادل، ثم قرر القاضي أن كود التعريف «نظام أو طريقة تشغيل» System or Method of Operation، وهو ما يستثنيه قانون حق المؤلف من الحماية.
• محكمة الاستئناف الفيدرالية نقضت ذلك وقالت إن كود التعريف وتنظيمه قابلان للحماية، لأن Google كان بإمكانها أن تكتب أسماءها الخاصة كما كتبت كود التنفيذ، وأعادت القضية لمحاكمة جديدة على الاستخدام العادل.
• في المحاكمة الثانية قررت هيئة المحلفين أن استخدام Google عادل، فنقضت محكمة الاستئناف هذا أيضاً وقالت إنه ليس عادلاً «كمسألة قانونية» As a Matter of Law، وقبل أن تبدأ محاكمة التعويضات وافقت المحكمة العليا على النظر في القضية.

ماذا قررت المحكمة العليا بالضبط؟

صدر الحكم في 5 أبريل 2021، والقرار الذي كتبته المحكمة في ملخص الحكم هو:

Google’s copying of the Java SE API, which included only those lines of code that were needed to allow programmers to put their accrued talents to work in a new and transformative program, was a fair use of that material as a matter of law.

أي أن نسخ Google لواجهة Java SE البرمجية، والذي اقتصر على الأسطر اللازمة ليستخدم المبرمجون خبرتهم التي اكتسبوها في برنامج جديد ومختلف Transformative، هو استخدام عادل كمسألة قانونية. وكتب رأي المحكمة القاضي Stephen Breyer وانضم إليه خمسة قضاة، وخالفه القاضي Clarence Thomas وانضم إليه القاضي Samuel Alito، ولم تشارك القاضية Amy Coney Barrett، فكانت النتيجة ستة أصوات مقابل صوتين، ونقضت المحكمة حكم الاستئناف وأعادت القضية.

والتفصيلة التي يخطئ فيها كثيرون هي أن المحكمة لم تقرر أن الواجهات البرمجية لا تحمى بحق المؤلف، فقد كتبت أنها، حتى لا تقرر أكثر مما تحتاجه القضية، تفترض جدلاً أن الأسطر المنسوخة قابلة للحماية، ثم تنظر فقط في هل كان الاستخدام عادلاً. ومن الأسباب التي ذكرتها:

• الأسطر المنسوخة جزء من واجهة يستخدمها المبرمجون، وقيمتها تأتي في جزء كبير منها من استثمار المبرمجين الذين تعلموا هذه الواجهة، وليس من إبداع كاتبها فقط.
• Google نسخت ما يكفي فقط ليعمل المبرمجون في بيئة جديدة هي الهواتف دون أن يتركوا لغة يعرفونها، وهذا استخدام تحويلي.
• الأسطر المنسوخة 11,500 سطر، وهي 0.4% فقط من واجهة Sun Java كاملة التي يبلغ حجمها مع كود التنفيذ 2.86 مليون سطر.

وما يعنيه هذا لك كمطور هو أن إعادة تطبيق واجهة معروفة، كما تفعل خدمات التخزين التي تطبق واجهة S3 أو قواعد البيانات التي تتحدث بروتوكول PostgreSQL، أصبح لها سابقة قوية في صالحها في القانون الأمريكي، ولكن السؤال الأعمق عن حماية الواجهات نفسها بقي دون إجابة من المحكمة العليا، وبالطبع هذا ليس رأياً قانونياً، وإنما قراءة لما كتبته المحكمة.

Java EE تخرج إلى مؤسسة Eclipse

الجزء الذي خرج من Oracle فعلاً هو مواصفات Java EE، ففي 12 سبتمبر 2017 أعلنت Oracle مع IBM وRed Hat نقلها إلى مؤسسة Eclipse، وأصبح اسمها Jakarta EE، ولأن كلمة Java علامة تجارية تملكها Oracle لم يستطع المجتمع تعديل الحزم تحت الاسم javax، فتغيرت كلها إلى jakarta في Jakarta EE 9 في ديسمبر 2020، وهذا هو السبب في أن التطبيقات القديمة لا تعمل على Tomcat 10 وما بعده دون تعديل. وقد شرحنا القصة كاملة بتواريخها ومصادرها، مع أثر تغيير الأسماء على السيرفرات وكيف تفحص اعتمادياتك قبل الترحيل، في قسم Jakarta EE: ماذا حدث لـ Java EE؟، فلن نعيدها هنا.

الانتظار الطويل لـ Java 9

إذا أردت أن تفهم لماذا تصدر Java اليوم كل ستة أشهر، فعليك أن تعرف أولاً كيف كانت تصدر قبل ذلك. فكل إصدار كبير كان مربوطاً بميزة أو ميزتين كبيرتين، ولا يخرج حتى تكتمل، وأوضح مثال على ذلك نظام الوحدات Module System الذي كان اسم مشروعه Jigsaw:

• في سبتمبر 2010، ومع الخطة B، أجل Jigsaw من JDK 7 إلى JDK 8.
• في يوليو 2012 كتب Mark Reinhold مقالاً بعنوان Jigsaw تأخر عن القطار اقترح فيه تأجيله مرة أخرى إلى Java 9، والسبب الذي ذكره أن تحويل المنصة نفسها إلى وحدات مع الحفاظ على توافق الكود القديم مهمة حساسة جداً، وأن الوقت المتبقي أقصر من التقييم والمراجعة التي يحتاجها تغيير بهذا الحجم، واقترح في المقال نفسه أن تصدر Java كل سنتين بانتظام.
• صدر JDK 8 في 18 مارس 2014 وميزته الرئيسية Lambda، وتذكر صفحته أن الموعد الأصلي كان سبتمبر 2013 ولكنه تأخر بسبب التركيز على المشاكل الأمنية المتعلقة بالمتصفح.
• في مايو 2017 رفضت اللجنة التنفيذية في JCP مواصفة نظام الوحدات JSR 376 في تصويت المراجعة العامة الذي امتد من 25 أبريل إلى 8 مايو، فصوت 10 أعضاء بنعم و13 بلا، ومنهم IBM وRed Hat، وكانت التعليقات المكتوبة تتحدث عن غياب التوافق داخل مجموعة الخبراء وعن مسار الانتقال للمكتبات وأدوات البناء الموجودة.
• بعد تعديلات على المواصفة صدر JDK 9 في 21 سبتمبر 2017 بنظام الوحدات (JEP 261)، أي بعد ثلاث سنوات ونصف من Java 8.

وتصويت 2017 هو مثال جيد على أن عملية JCP ليست مجرد شكل، فاللجنة رفضت مواصفة تقودها Oracle، واضطرت Oracle إلى معالجة الاعتراضات قبل الإصدار.

قطار الإصدارات كل ستة أشهر

في 6 سبتمبر 2017، أي قبل صدور Java 9 بأسبوعين، نشر Mark Reinhold مقالاً بعنوان Moving Java Forward Faster اعترف فيه بأن فكرة الإصدار كل سنتين «جذابة نظرياً ولكنها لم تنجح عملياً»، فقد أخذ Java 8 ثمانية أشهر إضافية، وأخذ Java 9 سنة إضافية. والحل الذي اقترحه هو نموذج «القطار» Train Model: يغادر القطار في موعده سواء كانت الميزة جاهزة أم لا، فإذا لم تكن جاهزة تنتظر القطار التالي، وبذلك لا تؤخر ميزة واحدة كل الميزات الأخرى. وتفاصيل الاقتراح كانت:

• إصدار ميزات Feature Release كل ستة أشهر، في مارس وسبتمبر، بدءاً من مارس 2018.
• تحديثات Update Releases كل ثلاثة أشهر في يناير وأبريل ويوليو وأكتوبر، وهي للإصلاحات الأمنية والأخطاء فقط.
• إصدار بدعم طويل Long-Term Support واختصاراً LTS كل ثلاث سنوات، بدءاً من سبتمبر 2018.

وفي هذا النموذج لاحظ أن الدعم الطويل ليس صفة في الكود، فكل الإصدارات تبنى بالطريقة نفسها في مشروع OpenJDK، وإنما هو وعد من الجهات التي تبني Java وتنشرها بأنها سوف تستمر في إصدار التحديثات لهذا الإصدار سنوات. وقد تغير الإيقاع بعد ذلك من ثلاث سنوات إلى سنتين، فخطة دعم Oracle تقول إن Java 8 و11 و17 و21 و25 إصدارات LTS، وإن Oracle تنوي إصدار LTS كل سنتين وإن التالي هو Java 29 في سبتمبر 2027، وصفحة دعم Temurin تقول الشيء نفسه بعبارة «كل سنتين منذ 2021». أما أرقام الإصدارات فقد اقترح Reinhold في البداية أن تكون بصيغة السنة والشهر مثل 18.3، ولكن JEP 322 اعتمد في النهاية الأرقام التي تعرفها اليوم: 10 ثم 11 ثم 12.

والصورة التالية تبين القطار منذ Java 10 كما تنشره صفحة مشروع JDK، مع الإصدارات طويلة الدعم:

والسؤال الذي يسأله كل فريق: هل ننتقل مع كل إصدار؟ والإجابة في الغالب لا، فأغلب الشركات تبقى على إصدارات LTS وتنتقل من واحد إلى التالي، والاستثناء هو الفرق التي تبني تطبيقها في Container مع إصدار Java المحدد له، فهذه تستطيع أن تنتقل كل ستة أشهر، وهو بالضبط ما توقعه مقال Reinhold نفسه عندما ذكر تسليم التطبيق في Docker Image مع إصدار Java الذي يعمل عليه.

جدول الإصدارات منذ Java 7

الجدول التالي يجمع كل إصدار منذ Java 7 مع تاريخ وصوله إلى الإتاحة العامة General Availability وأهم ما فيه، والتواريخ والميزات كلها من صفحات الإصدارات في مشروع OpenJDK ووثائق JEP التي تذكرها، ونبدأ من Java 7 لأنه أول إصدار له صفحة كاملة في OpenJDK، أما الإصدارات من 1.0 إلى 6 فكانت في زمن Sun قبل أن يصبح الكود مفتوحاً. والإصدارات طويلة الدعم مكتوب بجانبها LTS، وتذكر أن «Preview» تعني ميزة مكتملة ولكنها مؤقتة لجمع آراء المطورين، و«Incubator» تعني واجهة تجريبية في وحدة منفصلة.

في الجدول أعلاه لاحظ التالي:

• الفرق بين Java 8 وJava 9 ثلاث سنوات ونصف، وبعد Java 9 لم يتأخر أي إصدار عن موعده، وهذا هو الدليل العملي على نجاح نموذج القطار.
• كثير من الميزات الكبيرة مرت بعدة إصدارات كمعاينة قبل أن تصبح نهائية، فالخيوط الافتراضية مثلاً ظهرت معاينة في 19 و20 ثم أصبحت نهائية في 21، وهذا ما كان مستحيلاً في النموذج القديم حيث يكون أمام الميزة إصدار واحد كل بضع سنوات.
• إزالة الأجزاء القديمة تتم تدريجياً وعلى سنوات: إهمال ثم إهمال تمهيداً للحذف ثم حذف، كما رأينا في Applet من Java 9 إلى Java 26.

من يكتب Java اليوم؟

الكود كله في مستودع واحد على GitHub هو openjdk/jdk، وتديره Oracle، ولكن هل تكتبه Oracle وحدها؟ هنا يجب أن نكون دقيقين في المصدر: سجل المشاركين الرسمي في OpenJDK، أي صفحة Census، يذكر الأشخاص وأدوارهم في المشاريع، ولكنه لا يذكر الجهة التي يعمل لها كل شخص، لذلك لا توجد بيانات رسمية مستقلة عن توزيع المساهمات على الشركات. والأرقام الوحيدة المنشورة تأتي من Oracle نفسها في مقال الإعلان عن كل إصدار، حيث تعد البلاغات المغلقة في نظام JIRA وتنسبها إلى جهة الشخص المكلف بها.

ففي إعلان Java 25 تقول Oracle إن 2,606 بلاغاً أغلقت في هذا الإصدار، منها 1,655 أنجزها موظفو Oracle و951 ساهم بها باقي المجتمع، وإن المطورين المستقلين وحدهم ساهموا بنسبة 9% من الإصلاحات، وشكرت مطورين من Alibaba وAmazon وGoogle وIBM وIntel وISCAS وRed Hat وRivos وSAP وServiceNow ومن شركات أصغر مثل BellSoft. وفي المقال نفسه رقم أوسع: من 33,793 بلاغاً أغلقت من Java 11 إلى Java 25، أنجزت Oracle منها 23,762 وأنجز الآخرون 10,031، أي أن Oracle أنجزت قرابة 70% من البلاغات المغلقة. وفي إعلان Java 27 ذكرت Oracle جهات منها ARM وMicrosoft وNTT Data وNVIDIA وLoongson، وقالت إن المطورين المستقلين ساهموا بنسبة 16% من الإصلاحات، ولكنها لم تنشر هذه المرة عدد البلاغات لكل جهة.

والصورة التالية تبين أرقام Java 25 كما نشرتها Oracle:

وقد يتساءل البعض: إذا كانت Oracle تكتب 70% من الكود، فهل Java مشروع مفتوح حقاً؟ والإجابة أن الرخصة مفتوحة والعمل مفتوح في GitHub والقوائم البريدية، ولكن الحوكمة الفعلية بيد الشركة القائدة، وهذا نموذج «الشركة القائدة» Company-led الذي شرحناه في مقال الحوكمة. والذي يحمي المجتمع في هذا النموذج هو الرخصة GPLv2 مع الاستثناء، فلو توقفت Oracle غداً فإن Red Hat التي تقول في صفحة دعمها إنها من أكبر المساهمين من خارج Oracle، وAmazon وSAP وMicrosoft وغيرها تملك الكود والخبرة لتستمر، وقد شرحنا لماذا تستثمر الشركات الكبيرة في مشاريع كهذه في مقال لماذا تساهم الشركات الكبيرة في المصادر المفتوحة.

ماذا نتعلم من قصة Java؟

• الرخصة المفتوحة قبل البيع هي التي أنقذت المشروع: فتحت Sun كود Java قبل الشراء بثلاث سنوات، فلم يستطع أحد أن يغلقه بعد ذلك، بينما انقسمت مشاريع Sun الأخرى التي اختلف مجتمعها مع المالك الجديد.
• الإصدار المنتظم أفضل من الإصدار الكبير: ميزة واحدة متأخرة كانت تؤخر كل شيء سنوات، والقطار حل المشكلة دون أن يقلل جودة الإصدارات، وهذا درس يصلح لأي منتج تبنيه أنت.
• الواجهة ليست مثل الكود: حكم 2021 أعطى من يعيد تطبيق واجهة معروفة حجة قوية، ولكنه لم يقل إن الواجهات حرة، فاقرأ رخصة أي واجهة تبني عليها.
• العلامة التجارية شيء والكود شيء آخر: نقل Java EE إلى Eclipse نقل الكود والمواصفات، ولكن الاسم javax بقي مع Oracle، فدفع المطورون ثمن تغيير الحزم.

الخلاصة

وصلنا لنهاية القصة، وأهم ما فيها:

• صدرت Java 1.0 في 23 يناير 1996 بوعد «اكتب مرة وشغل في كل مكان»، وسقطت ال Applets تدريجياً حتى حذفت في Java 26، بينما وجدت Java مكانها الحقيقي في السيرفر.
• تأسست عملية JCP في 8 ديسمبر 1998، وما زالت لجنتها تصوت على كل إصدار، ورفضت في 2017 مواصفة الوحدات في التصويت الأول.
• أعلنت Sun فتح كود Java في 13 نوفمبر 2006 برخصة GPLv2، ونشرت JDK كاملاً قابلاً للبناء في مايو 2007، واستثناء Classpath هو الذي يسمح لتطبيقك بأن يكون بأي رخصة.
• أكملت Oracle شراء Sun في 27 يناير 2010، وغادر جوسلينج في أبريل، وخرجت MariaDB وLibreOffice وJenkins من مشاريع Sun السابقة.
• حكمت المحكمة العليا في 5 أبريل 2021 بستة أصوات مقابل صوتين أن نسخ Google لكود التعريف في واجهة Java SE استخدام عادل، دون أن تقرر هل الواجهات تحمى أم لا.
• بعد ثلاث سنوات ونصف بين Java 8 و9 تحولت Java إلى إصدار كل ستة أشهر منذ 2018، والإصدارات طويلة الدعم هي 8 و11 و17 و21 و25، والقادم 29 في سبتمبر 2027.
• بحسب أرقام Oracle أنجزت Oracle قرابة 70% من بلاغات JDK من Java 11 إلى 25، ولا توجد بيانات رسمية مستقلة عن توزيع المساهمات على الشركات.

دليلهل Java مجانية؟ أي JDK تستخدم في شركتكمتى تحتاج اشتراكاً في Oracle JDK ومتى لا تحتاجه، وكيف تعرف نسخ Java التي تعمل عندك وتنقلها إلى نسخة مجانية بأمان.دليلقصص لغات البرمجة ومن صنعها، من Fortran إلى Rustمن صنع اللغات التي نكتب بها كل يوم، وما المشكلة التي دفعته إلى ذلك، وكيف تشرح قصة كل لغة قراراتها.دليلاللغة شيء والمترجم شيء آخر: من يقرر مستقبل لغات البرمجة؟لماذا لا تصح جمل مثل «Python بطيئة»، وما الفرق بين مواصفة اللغة والبرامج التي تطبقها، ومن يقرر مستقبلها.دليلمشاريع مؤسسة Eclipse: من Jakarta EE إلى Mosquittoما الذي تستضيفه مؤسسة Eclipse غير المحرر الذي تعرفه، ولماذا تغيرت حزم Java من javax إلى jakarta.دليلمن يدير المشروع مفتوح المصدر؟ نماذج الحوكمة Governanceمن يقرر في مشروع يساهم فيه آلاف الأشخاص، ومن يستطيع تغيير رخصته، وما الذي تفحصه قبل أن تعتمد على أي مشروع.دليلما هي البرمجيات مفتوحة المصدر؟ القصة وأشهر الرخصكيف بدأت البرمجيات الحرة والمفتوحة، وما الفرق بين الحر والمجاني، وكيف تعرف ما تسمح به رخصة أي مشروع قبل أن تبني عليه.دليللماذا تساهم الشركات الكبيرة في المصادر المفتوحة، ولماذا نغيب نحن عنها؟موظفو Intel وGoogle وRed Hat يكتبون جزءاً كبيراً من نواة Linux وKubernetes، ولذلك أسباب اقتصادية مكتوبة. أعرض الأدلة والأسباب وأرقام منطقتنا، ثم رأيي فيما يكلفنا غيابنا وما تستطيع شركتك أن تبدأ به هذا الربع.دليلأدوات البناء Build Tools وماذا يحدث عندما تبني مشروعكما الذي يحدث بين ضغطة البناء والملف الناتج، ولماذا ينجح البناء على جهازك ويفشل على سيرفر CI، ومتى يعطيك نفس النتيجة مرتين.

سجل التحديثات

• أكتوبر 2026: كتابة المقال من المصادر الأولية: إعلانات Sun وOracle المحفوظة في أرشيف الإنترنت، وصفحات الإصدارات ووثائق JEP في openjdk.org، ونص حكم المحكمة العليا الأمريكية، ونتائج التصويت في jcp.org، ومقالات Oracle عند إصدار Java 25 وJava 27.