Gavin King [1], bapak Hibernate, merekomendasikan agar pengembang melakukan upgrade ke platform Java EE 6, dan menunjukkan bahwa keengganan saat ini untuk melakukan upgrade sebenarnya tidak berdasar.
Setelah Java EE 6 dirilis, saya melihat banyak penolakan untuk mengupgrade ke platform baru. Sebagian besar keberatan ini diajukan oleh pengguna Tomcat/Jetty dan beberapa kerangka kerja sumber terbuka (seperti Hibernate dan Spring).
Tentu saja, ada banyak keuntungan memilih teknologi sumber terbuka yang non-standar. Selain itu, di EE 6, Anda dapat menggunakan kerangka kerja sumber terbuka yang Anda minati. Servlet 3 dan CDI dapat mengintegrasikan kerangka kerja pihak ketiga dengan mulus. Jadi tidak ada alasan untuk tidak menggunakan EE 6. Namun, saya melihat seseorang berkata:
Mengupgrade ke Server Aplikasi EE itu Sulit
Hal ini tampaknya merupakan masalah politik bagi organisasi tertentu dan bukan masalah teknis yang sebenarnya. Tentu saja, mengupgrade server seperti GlassFish atau JBoss adalah tugas yang sangat sepele. (Memperbarui kerangka kerja pihak ketiga bahkan lebih menyakitkan lagi.) Beberapa organisasi mempunyai proses yang sangat berat untuk memperbarui server, namun tidak begitu banyak untuk memperbarui kerangka kerja yang berjalan di dalam server. Oleh karena itu, lebih mudah bagi tim pengembangan untuk meningkatkan kerangka kerja pihak ketiga.
Saya pikir mengembangkan proses yang lebih meyakinkan dan lebih baik adalah hal yang paling penting, daripada meninggalkan Java EE. Ada banyak risiko yang terkait dengan menjalankan aplikasi Anda pada platform server lama dan ketinggalan jaman, dan proses tersebut tidak boleh mendorong praktik semacam itu.
Namun dari sudut pandang praktis, hampir semua orang berencana untuk mengupgrade ke Servlet 3 dalam waktu dekat. Apakah Anda menggunakan Tomcat, Jetty, JBoss, GlassFish, Resin, WebLogic, Oracle atau WebSphere, itu berarti peningkatan server. Ini adalah peluang bagus untuk meningkatkan ke Profil Web EE 6, waktu emas.
Server aplikasi EE terlalu besar
Keberatannya adalah EE Server berisi banyak fitur yang (saat ini) tidak tersedia. Argumen lawan biasanya melibatkan pembahasan ukuran paket jar dan ruang disk yang ditempati oleh mesin Servlet + kerangka pihak ketiga dan server aplikasi EE. Faktanya, argumen ini bermasalah:
Penggunaan disk dan ruang disk yang dibahas sebenarnya sepele jika diukur dalam $, dan paket perang aplikasi jauh lebih penting daripada ukuran paket instalasi server. Server sebenarnya memiliki banyak fungsi untuk meminimalkan ukuran perang.
Selain itu, menurut saya yang paling meyakinkan adalah Java EE 6 Web Profile tidak besar sama sekali. Setelah server Profil Web bersertifikat tersedia di pasaran, kita dapat menemukan keseimbangan antara server aplikasi EE besar dan wadah Servlet kecil.
J2EE dan EJB2 buruk!
Dengan adanya proses standardisasi JCP, permasalahan ini sebenarnya sudah tidak ada lagi:
1. Sudah 8 tahun sejak EJB2 muncul! Apakah itu masih pilihan terbaikmu?
2. Spesifikasi yang baik telah digabungkan melalui standarisasi JCP yang berkelanjutan, dan beberapa di antaranya dapat digunakan dengan sangat pasti. Namun JCP tidak 100% berhasil dalam standardisasi.
3. Semua orang yang bekerja pada platform EE 6 membenci EJB2 dan J2EE. Itu sebabnya orang-orang terus bergabung dengan JCP untuk membantu memperbaiki masalah ini. Misalnya saja pendiri Hibernate dan penulis artikel ini. Apakah Anda benar-benar ingin memberinya pelajaran tentang EJB2? :-)
4. Hampir semua orang yang bekerja di Entity Beans sudah pensiun sekarang!
Faktanya, Profil Web Java EE 6 sudah cukup. Jika Anda tidak mencoba Java EE 6 sendiri, Anda tidak akan bisa merasakan manfaat EE6 untuk pengembangan.
Portabilitas server aplikasi sungguh sebuah misteri!
Benar-benar? Kami melihat banyak orang memisahkan aplikasi mereka dan menyebarkannya di server aplikasi yang berbeda? Oh, saya pernah melihat aplikasi porting 0-perubahan yang 100% sempurna, sebuah cita-cita portabilitas Platonis. Saya memahami kelemahan kebenaran absolut dan cita-cita Platonis, tapi mari kita lihat contohnya terlebih dahulu.
Berikut ini gambaran umum dari masalah portabilitas:
9% kode, 85% metadata eksternal sepenuhnya kompatibel pada platform server yang berbeda, dan 1% dan 15% sisanya dapat dibagi dengan tepat
Kode 0%, 80% metadata eksternal terkait dengan arsitektur kontainer vendor tunggal non-standar
Saat saya membagi poin-poin ini, tiba-tiba saya ingin mengubah topik bagian ini dari portabilitas server aplikasi yang terlalu misterius menjadi saya tidak peduli sama sekali tentang portabilitas container. Gagasan perubahan tema menegaskan bahwa masalah portabilitas server adalah nyata dan akan sangat berguna bagi banyak organisasi.
Saya selalu ingin melihat ulasan nyata tentang EE 6 dari pengelola teknis non-EE 6. Beberapa argumen yang disebutkan di atas tidak berasal dari dunia nyata, sehingga sulit untuk memicu diskusi mengenai masalah teknis aktual pengembangan aplikasi pada platform EE. Spesifikasi JCP putaran terbaru tampaknya telah meninggalkan kubu anti-EE (sementara?), tetapi tidak memiliki dukungan faktual untuk keberhasilan.
Catatan Redaksi:
[1] Gavin King: Pendiri Hibernate, anggota Komite Ahli EJB3, salah satu anggota inti JBoss, pemimpin kerangka Seam, pemimpin spesifikasi JSR-299 (CDI), dan penulis buku "Hibernate in Action" .
Sumber: Anda harus meningkatkan ke Java EE 6