لأكثر من عقدين، شكّلت Java EE (Java Platform, Enterprise Edition) العمود الفقري لتطوير تطبيقات المؤسسات في عالم Java. استخدمها المطوّرون لبناء أنظمة ضخمة تعتمد على الخوادم، المعاملات، الأمان، والتكامل مع قواعد البيانات.
لكن ابتداءً من عام 2017–2018، حدث تحوّل جذري في مستقبل Java EE تمثّل في نقلها من Oracle إلى Eclipse Foundation، وولادة منصّة جديدة باسم Jakarta EE.
هذا الانتقال لم يكن مجرّد تغيير اسم، بل أعاد رسم مستقبل Java المؤسسية بالكامل.
أولًا: ما هي Java EE؟
Java EE كانت مواصفة (Specification) مملوكة ومدارة من قبل Oracle، وتهدف إلى توفير:
-
بيئة قياسية لتطوير تطبيقات المؤسسات
-
مجموعة APIs جاهزة مثل:
-
Servlets
-
JSP / JSF
-
EJB
-
JPA
-
JAX-RS
-
JMS
-
-
مفهوم Application Server (مثل WebLogic, JBoss, GlassFish)
مشاكل Java EE قبل الانتقال
قبل نقلها، عانت Java EE من عدة إشكالات:
-
بطء شديد في التطوير
-
إصدارات متباعدة
-
تأخر كبير في دعم التقنيات الحديثة (Cloud, Microservices)
-
-
تعقيد مفرط
-
APIs ثقيلة
-
Configuration معقّد
-
اعتماد كبير على XML
-
-
هيمنة Oracle
-
تحكّم مركزي
-
ضعف مشاركة المجتمع
-
غموض في مستقبل المنصة
-
ثانيًا: لماذا تم نقل Java EE إلى Eclipse؟
في 2017 أعلنت Oracle رسميًا أنها:
-
لن تستثمر مستقبلًا في تطوير Java EE
-
ستنقل الملكية الفكرية إلى Eclipse Foundation
أهداف النقل
-
فتح التطوير أمام المجتمع (Vendor-neutral)
-
تسريع الابتكار
-
جعل المنصة مناسبة للعصر الحديث (Cloud-native)
-
كسر الاحتكار
لكن ظهرت مشكلة قانونية كبيرة…
ثالثًا: المشكلة القانونية – اسم Java
كلمة Java هي علامة تجارية مملوكة لـ Oracle.
وبالتالي:
-
لا يمكن لـ Eclipse استخدام اسم Java EE
-
لا يمكن استخدام الحزمة
javax.*مستقبلًا
الحل: Jakarta EE
تم اختيار اسم جديد:
Jakarta EE
وبهذا بدأ فصل جديد في تاريخ Java المؤسسية.
رابعًا: الفرق الجوهري بين Java EE و Jakarta EE
1. الجهة المالكة والحوكمة
| العنصر | Java EE | Jakarta EE |
|---|---|---|
| الجهة | Oracle | Eclipse Foundation |
| الحوكمة | مركزية | مفتوحة / مجتمعية |
| الشفافية | محدودة | عالية جدًا |
Jakarta EE تُدار بواسطة:
-
شركات (Red Hat, IBM, Payara, Tomitribe…)
-
مجتمع مفتوح
-
لجان تقنية (Specification Committees)
2. التسمية والحزم (Packages)
Java EE
Jakarta EE
🔴 هذا هو التغيير الأكثر تأثيرًا عمليًا.
ابتداءً من Jakarta EE 9، تم نقل كل شيء من
javax.*إلىjakarta.*
3. التوافق (Compatibility)
-
Jakarta EE 8
🔹 متوافق 100% مع Java EE 8
🔹 ما زال يستخدمjavax.* -
Jakarta EE 9 وما بعدها
🔹 كسر التوافق (Breaking Change)
🔹 استخدامjakarta.*فقط
هذا يعني:
-
أي تطبيق Java EE قديم يحتاج Migration
-
لا يمكن تشغيله مباشرة على Jakarta EE 9+
4. الفلسفة المعمارية
Java EE (قديمًا)
-
Monolithic Applications
-
Heavy Application Servers
-
Stateful EJBs
-
XML Configuration
Jakarta EE (حديثًا)
-
Cloud-Native
-
Microservices-Friendly
-
Stateless Design
-
CDI + REST
-
تكامل ممتاز مع:
-
Kubernetes
-
Docker
-
MicroProfile
-
5. سرعة التطوير والابتكار
| جانب | Java EE | Jakarta EE |
|---|---|---|
| دورة الإصدارات | بطيئة | سريعة |
| التحديثات | نادرة | منتظمة |
| التفاعل المجتمعي | ضعيف | قوي |
Eclipse تعتمد نموذج Agile Specification Development بدل النهج البيروقراطي القديم.
خامسًا: Jakarta EE و MicroProfile
من أهم مكاسب الانتقال:
-
Eclipse MicroProfile
-
مجموعة APIs خفيفة لـ Microservices:
-
Config
-
Health Check
-
Metrics
-
Fault Tolerance
-
JWT Security
-
Jakarta EE + MicroProfile =
منصة حديثة تنافس Spring Boot فعليًا
سادسًا: ماذا يعني هذا للمطوّر؟
إن كنت مطوّر Java EE قديم
-
لا حاجة للذعر
-
تطبيقات Java EE 8 ما زالت تعمل
-
لكن:
-
المستقبل = Jakarta EE
-
يجب التخطيط للـ Migration
-
إن كنت تبدأ مشروعًا جديدًا
✅ اختر Jakarta EE مباشرة
خصوصًا مع:
-
Payara
-
WildFly
-
Open Liberty
-
Quarkus (يدعم Jakarta APIs)
سابعًا: هل Jakarta EE أفضل من Java EE؟
تقنيًا وعمليًا: نعم.
لأن Jakarta EE:
-
أكثر انفتاحًا
-
أسرع تطورًا
-
مناسبة للـ Cloud
-
غير مرتبطة بشركة واحدة
-
مستقبلها أوضح
لكن:
-
تكلفة الانتقال موجودة
-
كسر التوافق كان مؤلمًا
خاتمة
الفرق الحقيقي بين Java EE و Jakarta EE ليس مجرد تغيير اسم أو حزم (Packages)، بل هو:
-
انتقال من منصة جامدة إلى نظام بيئي حي
-
من تحكّم مركزي إلى حوكمة مجتمعية
-
من Enterprise تقليدي إلى Cloud-Native Java
Jakarta EE ليست بديلًا لـ Java EE فقط، بل هي إنقاذها الحقيقي.