OSGi, Java Modularity dan Jigsaw

Jadi sampai kemarin pagi saya tidak tahu apa itu OSGi. OSGi hanyalah kata kunci yang saya lihat terus muncul berulang kali, jadi saya akhirnya menyisihkan waktu untuk memolesnya.

Ini sebenarnya tampak seperti hal yang cukup keren, jadi saya ingin memulai dengan menyatakan (sebagai catatan) bahwa saya sama sekali bukan anti-OSGi, juga bukan pertanyaan "OSGi-bashing".

Pada akhirnya, tampaknya OSGi telah - pada dasarnya - menangani JSR 277 pada Java Modularity, yang mengakui bahwa ada kekurangan dengan JARspesifikasi file yang dapat menyebabkan resolusi namespace dan masalah pemuatan kelas dalam kasus sudut tertentu. OSGi juga melakukan banyak hal lain yang sangat keren, tapi dari apa yang bisa saya pastikan, itulah hasil imbang terbesarnya (atau salah satunya).

Bagi saya - sebagai pengembang Java EE yang cukup baru (beberapa tahun sekarang), sungguh mengejutkan bahwa kita berada di tahun 2011 dan saat ini hidup di era Java 7, dan bahwa masalah pemuatan kelas ini masih ada; terutama dalam lingkungan perusahaan di mana satu server aplikasi dapat memiliki ratusan JAR di dalamnya, dengan banyak di antaranya bergantung pada versi yang berbeda satu sama lain dan semuanya berjalan (kurang lebih) secara bersamaan.

Pertanyaan saya:

Sama tertariknya dengan saya pada OSGi, dan sebanyak saya ingin mulai mempelajarinya untuk melihat di mana / apakah itu dapat berguna untuk proyek saya, saya hanya tidak punya waktu untuk duduk dan mempelajari sesuatu yang besar, setidaknya sekarang.

Jadi apa yang harus dilakukan oleh pengembang non-OSGi saat masalah ini muncul? Apa solusi Java (Oracle / Sun / JCP) yang ada saat ini, jika ada? Mengapa Jigsaw dipotong dari J7? Seberapa yakin komunitas bahwa Jigsaw akan diimplementasikan tahun depan di J8? Apakah mungkin mendapatkan Jigsaw untuk proyek Anda meskipun itu belum menjadi bagian dari platform Java?

Saya rasa yang saya tanyakan di sini adalah kombinasi dari kepanikan, intrik, dan ketenangan. Sekarang saya akhirnya mengerti apa itu OSGi, saya hanya tidak "mengerti" bagaimana sesuatu seperti Jigsaw membutuhkan waktu 20+ tahun untuk membuahkan hasil, dan kemudian bagaimana itu bisa dikalengkan dari rilis. Sepertinya fundamental.

Dan, sebagai developer, saya juga penasaran seperti apa solusi saya, sans OSGi.

Juga, Catatan : Saya tahu ini bukan pertanyaan jenis " pemrograman murni ", tetapi sebelum beberapa dari Anda membuat hidung bengkok, saya ingin menyatakan (sekali lagi, sebagai catatan) bahwa saya sengaja mengajukan pertanyaan ini BEGITU. Itu karena saya sangat menghormati sesama SOers dan saya mencari jawaban tingkat arsitektur dari beberapa "Dewa TI" yang saya lihat bersembunyi di sekitar sini setiap hari.

Namun, bagi Anda yang benar-benar bersikeras bahwa pertanyaan SO harus didukung dengan beberapa segmen kode:

int x = 9;

(Terima kasih kepada siapa saja yang dapat mempertimbangkan hal-hal OSGi / Jigsaw / classloader / namespace / JAR ini!)

Pertama, pahami bahwa kasus penggunaan utama Jigsaw adalah memodulasi JRE itu sendiri. Sebagai tujuan sekunder, ia akan menawarkan sistem modul yang dapat digunakan oleh pustaka dan aplikasi Java lainnya.

Posisi saya adalah bahwa sesuatu seperti Jigsaw mungkin diperlukan hanya untuk JRE, tetapi itu akan menciptakan lebih banyak masalah daripada yang diklaim untuk diselesaikan jika digunakan oleh perpustakaan atau aplikasi Java lainnya.

JRE adalah kasus yang sangat sulit dan khusus. Itu sudah lebih dari 12 tahun dan merupakan kekacauan yang mengerikan, penuh dengan siklus ketergantungan dan ketergantungan yang tidak masuk akal. Pada saat yang sama digunakan oleh sekitar 9 juta pengembang dan mungkin milyaran sistem yang sedang berjalan. Oleh karena itu, Anda benar-benar tidak dapat melakukan refaktorisasi JRE jika pemfaktoran ulang tersebut membuat perubahan yang mengganggu.

OSGi adalah sistem modul yang membantu Anda (atau bahkan memaksa Anda untuk) membuat perangkat lunak yang modular. Anda tidak bisa begitu saja menaburkan modularitas di atas basis kode non-modular yang ada. Membuat basis kode non-modular menjadi basis kode modular pasti memerlukan beberapa pemfaktoran ulang: memindahkan kelas ke dalam paket yang benar, mengganti pembuatan instance langsung dengan penggunaan layanan terpisah, dan seterusnya.

Hal ini mempersulit penerapan OSGi secara langsung ke basis kode JRE, namun kami masih memiliki persyaratan untuk membagi JRE menjadi beberapa bagian atau "modul" yang terpisah sehingga versi cut-down JRE dapat dikirimkan.

Oleh karena itu, saya menganggap Jigsaw sebagai semacam " tindakan ekstrem " untuk menjaga kode JRE tetap hidup saat memecahnya. Itu tidak membantu kode menjadi lebih modular, dan saya yakin bahwa itu benar-benar akan meningkatkan pemeliharaan yang diperlukan untuk mengembangkan perpustakaan atau aplikasi apa pun yang menggunakannya.

Terakhir: OSGi ada sedangkan Jigsaw belum ada dan mungkin tidak pernah ada. Komunitas OSGi memiliki pengalaman 12 tahun dalam mengembangkan aplikasi modular. Jika Anda sangat tertarik untuk mengembangkan aplikasi modular, OSGi adalah satu-satunya game di kota.

Sederhana saja, jika Anda ingin melakukan pengembangan berbasis komponen nyata di Java saat ini, maka OSGi adalah satu-satunya permainan di kota.

Menurut pendapat saya, Jigsaw adalah kombinasi dari kompromi dari apa yang bisa dilakukan di JDK dan hubungan buruk sebelumnya antara SUN dan OSGi guys. Mungkin itu akan dikirimkan dengan Java 8, tapi kita harus menunggu dan melihat.

OSGi bukanlah obat mujarab jika Anda bekerja di lingkungan perusahaan yang khas dan Anda harus terbiasa dengan cara kerja pemuatan kelas karena sejumlah pustaka terkenal (melihat Anda, Hibernate) membuat asumsi tentang visibilitas kelas yang tidak lagi valid di dalam OSGi.

Saya suka OSGi, tapi saya tidak akan mencoba dan retrofit ke sistem yang sudah ada. Saya juga akan mempertimbangkan pro dan kontra dalam hal pengembangan greenfield - Saya akan merekomendasikan untuk melihat produk Apache atau Eclipse yang menyederhanakan hidup OSGi dan tidak melakukannya sendiri.

Jika Anda tidak menggunakan OSGi, maka Anda kurang beruntung jika Anda telah menemukan sistem yang memiliki ketergantungan pada versi berbeda dari pustaka yang sama - yang dapat Anda lakukan hanyalah mencoba dan menghindari masalah, meskipun membutuhkan beberapa versi a perpustakaan tampaknya seperti 'bau' arsitektur bagi saya.

Saya senang Anda menggunakan frasa "kasus sudut" untuk menggambarkan situasi saat ini.

Ada kekurangan dengan spesifikasi file JAR yang dapat menyebabkan resolusi namespace dan masalah pemuatan kelas dalam kasus sudut tertentu

Bagaimanapun, sejak bertahun-tahun saya telah tertarik pada alat dan teknik yang mendukung pembuatan dan, bahkan lebih baik, menegakkan, kode yang lebih bersih, lebih terpisah, lebih koheren dan lebih dapat dipelihara daripada apa yang mungkin akan menjadi hasil tanpa mereka. Test Driven Design dan Junit adalah kombinasi seperti itu.

Setelah menghabiskan beberapa bulan memindahkan sebagian besar basis kode kami ke OSGi, saya akan mengatakan bahwa OSGi adalah alat yang lebih baik dalam hal ini. Dan itu adalah alasan yang cukup untuk pindah ke OSGi. Dalam jangka panjang, ini akan menghemat banyak uang.

Dan, sebagai bonus, ini akan memberi Anda kesempatan untuk melakukan banyak hal keren. Bayangkan, selama demo, meningkatkan modul otentikasi dengan mulus, tanpa kehilangan lalu lintas, untuk mendukung OAuth ... tiba-tiba menyenangkan lagi untuk membuat sesuatu!