Java EE vs J2EE vs Jakarta EE

1. Perkenalan

Pernah dengar Java EE? Bagaimana dengan Java 2EE, J2EE, atau sekarang Jakarta EE? Sebenarnya, ini semua adalah nama yang berbeda untuk hal yang sama: satu set spesifikasi perusahaan yang memperluas Java SE.

Dalam artikel singkat ini, kami akan menjelaskan evolusi Java EE.

2. Sejarah

Pada versi pertama Java, ekstensi perusahaan Java hanyalah bagian dari JDK inti.

Kemudian, sebagai bagian dari Java 2 pada tahun 1999, ekstensi ini dipecah dari binari standar, dan J2EE , atau Java 2 Platform Enterprise Edition, lahir. Itu akan mempertahankan nama itu hingga 2006.

Untuk Java 5 pada tahun 2006, J2EE diubah namanya menjadi Java EE atau Java Platform Enterprise Edition. Nama itu akan bertahan hingga September 2017, ketika sesuatu yang besar terjadi .

Lihat, pada September 2017, Oracle memutuskan untuk memberikan hak Java EE kepada Eclipse Foundation (bahasanya masih dimiliki oleh Oracle) .

3. Dalam Transisi

Sebenarnya Eclipse Foundation secara legal harus mengganti nama Java EE. Itu karena Oracle memiliki hak atas merek "Java".

Maka untuk memilih nama baru, masyarakat memilih dan memilih: Jakarta EE. Dalam hal tertentu, ini tetap J EE.

* Nama baru diumumkan

Ini masih merupakan cerita yang berkembang, dan debunya belum sepenuhnya mengendap.

Misalnya, meskipun Oracle membuat kode sumber terbuka, mereka tidak membuat semua dokumentasi menjadi sumber terbuka. Masih banyak pembahasan mengenai hal ini karena masalah hukum yang membuat dokumentasi open source terkait, misalnya JMS dan EJB menjadi rumit.

Belum jelas apakah dokumentasi Eclipse Foundation baru dapat merujuk ke aslinya.

Selain itu, anehnya, Eclipse Foundation tidak dapat membuat paket Java baru menggunakan namespace javax , tetapi dapat membuat kelas dan subclass baru di bawah yang sudah ada.

Transisi juga berarti proses baru untuk menambah spesifikasi pada Jakarta EE. Untuk memahaminya dengan lebih baik, mari kita lihat seperti apa proses itu di bawah Oracle dan bagaimana itu berubah di bawah Eclipse Foundation.

4. Masa Depan

Secara historis, untuk membuat fitur menjadi "EE", kami membutuhkan tiga hal: spesifikasi, implementasi referensi, dan pengujian. Ketiga hal ini dapat disediakan oleh siapa saja di komunitas, dan Komite Eksekutif akan memutuskan kapan ini siap untuk ditambahkan ke bahasa.

Untuk lebih memahami proses sebelumnya, mari kita lihat lebih dekat apa itu JSR, Glassfish, dan TCK dan bagaimana mereka mewujudkan fitur EE baru .

Kami juga akan melihat sekilas tentang apa yang diharapkan di masa depan.

4.1. JCP dan Sekarang, EFSP

Dulu, proses lahirnya fitur EE baru disebut Java Community Process (JCP).

Java SE masih menggunakan JCP sampai sekarang. Namun, karena EE telah mengubah kepemilikannya, dari Oracle ke Eclipse Foundation, kami memiliki proses baru dan terpisah untuk itu. Ini adalah Proses Spesifikasi Yayasan Eclipse (EFSP) dan ini merupakan perpanjangan dari Proses Pengembangan Eclipse.

Namun, ada beberapa perbedaan penting, sebagian besar seputar “Transparansi, Keterbukaan, Beban Bersama, dan Netralitas Vendor”. Penyelenggara EFSP, misalnya, membayangkan kelompok kerja kolaboratif yang netral vendor, proses sertifikasi yang swalayan, dan organisasi yang beroperasi dan mengatur sebagai meritokrasi.

4.2. JSR

Di JCP, langkah pertama untuk menambahkan fitur ke EE adalah membuat Permintaan Spesifikasi JSR atau Java. JSR agak mirip dengan antarmuka untuk fitur EE. Komite Eksekutif JCP meninjau dan menyetujui JSR yang telah selesai, dan kemudian kontributor JSR akan mengkodekannya dan membuatnya tersedia untuk komunitas.

Contoh bagusnya adalah JSR-339 - atau JAX-RS - yang awalnya diusulkan pada tahun 2011, disetujui oleh JCP pada tahun 2012 dan akhirnya dirilis pada tahun 2013.

Dan sementara komunitas selalu dapat mempertimbangkan saat spesifikasi sedang dibahas, waktu menunjukkan bahwa pendekatan yang mengutamakan penerapan - seperti dalam kasus JSR 310, java.time, dan Joda Time - cenderung membuat fitur dan API yang lebih diterima secara luas. .

Jadi, EFSP mencerminkan tampilan pertama kode ini dalam tujuan yang dinyatakan: "EFSP akan didasarkan pada percobaan langsung dan pengkodean terlebih dahulu, sebagai cara untuk membuktikan bahwa sesuatu layak untuk didokumentasikan dalam spesifikasi."

4.3. Ikan kaca

Kemudian, sebagai bagian dari JCP, JSR membutuhkan implementasi referensi. Ini agak mirip dengan kelas yang mengimplementasikan antarmuka . Implementasi referensi membantu pengembang pustaka yang kompatibel atau organisasi lain yang ingin membuat implementasi spesifikasi mereka sendiri.

Untuk fitur Java EE, JCP menggunakan Glassfish untuk implementasi referensinya.

Dan sementara sentralisasi pada Glassfish ini menyederhanakan proses penemuan untuk pelaksana, sentralisasi itu juga membutuhkan lebih banyak tata kelola dan cenderung lebih menyukai satu vendor daripada yang lain.

Oleh karena itu, EFSP tidak memerlukan implementasi referensi, melainkan hanya implementasi yang kompatibel . Sederhananya, perubahan halus ini membuat implementasi di dalam arsitektur pusat, seperti Glassfish, tidak akan disukai oleh yayasan secara tidak sengaja.

4.4. TCK

Terakhir, JCP mengharuskan fitur EE diuji melalui Kit Kompatibilitas Teknologi, atau TCK.

TCK adalah serangkaian pengujian untuk memvalidasi EE JSR tertentu. Sederhananya, untuk mematuhi Java EE, server aplikasi perlu mengimplementasikan semua JSR-nya dan lulus semua pengujian pada TCK yang ditunjuk.

Tidak banyak perubahan disini. Oracle membuka TCK serta EE JSR sebagai sumber terbuka. Tentu saja, semua dokumen masa depan dan TCK akan menjadi sumber terbuka.

5. Kesimpulan

Java EE pasti banyak berkembang selama tahun-tahun itu. Senang melihatnya terus berubah dan meningkat.

Ada banyak tantangan ke depan, jadi mari berharap transisi yang mulus.