OSGi, Java Modularity ve Jigsaw

Yani dün sabah itibariyle OSGi'nin ne olduğu konusunda hiçbir fikrim yoktu. OSGi , sürekli kırpıldığını gördüğüm bir moda kelimeydi ve bu yüzden sonunda onu tazelemek için biraz zaman ayırdım.

Aslında oldukça havalı bir şey gibi görünüyor, bu yüzden (kayıt için) hiçbir bakımdan OSGi karşıtı olmadığımı ve bunun bir "OSGi-dayak" sorusu olmadığını belirterek başlamak istiyorum.

Günün sonunda, OSGi'nin - esasen - Java Modularity üzerine JSR 277'yi ele aldığı görülüyor; bu, JARdosya spesifikasyonunda bazı köşe durumlarda ad alanı çözümlemesi ve sınıf yükleme sorunlarına yol açabilecek eksiklikler olduğunu fark etti . OSGi aynı zamanda başka pek çok harika şey de yapıyor, ancak anlayabildiğim kadarıyla, bu onun en büyük çekiciliği (veya onlardan biri).

Bana göre - oldukça yeni (birkaç yıldır) bir Java EE geliştiricisi olarak, 2011 yılında olmamız ve şu anda Java 7 çağında yaşıyor olmamız ve bu sınıf yükleme sorunlarının hala mevcut olması kesinlikle akıllara durgunluk veriyor; özellikle bir uygulama sunucusunun üzerinde yüzlerce JAR bulunabileceği kurumsal ortamlarda, bunların çoğu birbirinin farklı sürümlerine bağlıdır ve tümü aynı anda (az ya da çok) çalışır.

Benim sorum:

OSGi ile ilgilendiğim kadar ve projelerim için nerede / işe yarayıp yaramayacağını görmek için onu öğrenmeye başlamak istediğim kadar, oturup bu kadar büyük bir şey öğrenmek için zamanım yok. En azından şimdi.

Peki, OSGi olmayan geliştiriciler bu sorunlar ortaya çıktığında ne yapmalı? Varsa, şu anda hangi Java (Oracle / Sun / JCP) çözümleri mevcuttur? Jigsaw neden J7'den kesildi? Jigsaw'un gelecek yıl J8'de uygulanacağı topluluk ne kadar emin? Henüz Java platformunun bir parçası olmamasına rağmen projeniz için Jigsaw almanız mümkün mü?

Sanırım burada sorduğum şey panik, entrika ve facepalm kombinasyonu. Artık OSGi'nin ne olduğunu nihayet anladığıma göre, Jigsaw gibi bir şeyin nasıl sonuç vermesinin 20 yıldan fazla sürdüğünü ve daha sonra bunun bir sürümden nasıl korunabileceğini "anlamıyorum". Sadece temel görünüyor.

Ve bir geliştirici olarak, çözümlerimin ne olduğunu da merak ediyorum, sans OSGi.

Ayrıca, Not : Bunun " saf programlama " tipi bir soru olmadığını biliyorum , ancak bazılarınız burunlarınızı şekilden kurtarmadan önce, bu soruyu kasıtlı olarak sorduğumu belirtmek istedim (yine kayıt için) YANİ. Bunun nedeni, SO'lu arkadaşlarıma en büyük saygımdan başka hiçbir şeyim olmadığı ve her gün burada gizlendiğini gördüğüm bazı "BT Tanrıları" ndan mimari düzeyde bir cevap arıyorum.

Ancak, bir SO sorusunun bazı kod bölümleriyle desteklenmesinde kesinlikle ısrar edenler için :

int x = 9;

(Bu OSGi / Jigsaw / classloader / namespace / JAR cehennem şeylerine ağırlık verebilecek herkese teşekkürler!)

Öncelikle, Jigsaw'un birincil kullanım durumunun JRE'nin kendisini modüler hale getirmek olduğunu anlayın. İkincil bir amaç olarak, diğer Java kitaplıkları ve uygulamaları tarafından kullanılabilecek bir modül sistemi sunacaktır.

Benim görüşüm, Jigsaw gibi bir şeyin muhtemelen yalnızca JRE için gerekli olduğu, ancak diğer Java kitaplıkları veya uygulamaları tarafından kullanıldığında çözüldüğünü iddia ettiğinden çok daha fazla sorun yaratacağı yönünde.

JRE çok zor ve özel bir durumdur. 12 yaşın üzerinde ve bağımlılık döngüleri ve anlamsız bağımlılıklarla dolu korkunç bir karmaşa. Aynı zamanda yaklaşık 9 milyon geliştirici ve muhtemelen milyarlarca çalışan sistem tarafından kullanılmaktadır. Bu nedenle, bu yeniden düzenleme önemli değişiklikler yaratıyorsa, JRE'yi kesinlikle yeniden düzenleyemezsiniz.

OSGi, modüler bir yazılım oluşturmanıza yardımcı olan (hatta sizi buna zorlayan ) bir modül sistemidir . Mevcut modüler olmayan bir kod tabanının üzerine modülerliği basitçe serpemezsiniz. Modüler olmayan bir kod tabanını modüler bir kod tabanına dönüştürmek, kaçınılmaz olarak bazı yeniden düzenleme gerektirir: sınıfları doğru pakete taşımak, doğrudan başlatmayı, ayrıştırılmış hizmetlerin kullanımıyla değiştirmek, vb.

Bu, OSGi'yi doğrudan JRE kod tabanına uygulamayı zorlaştırır, ancak yine de JRE'yi ayrı parçalara veya "modüllere" bölme zorunluluğumuz vardır, böylece JRE'nin azaltılmış sürümleri teslim edilebilir.

Bu nedenle Jigsaw'u , JRE kodunu bölerken canlı tutmak için bir tür " aşırı önlem " olarak görüyorum . It does not daha modüler hale yardım kodunu ve bunu aslında kullandığı bunu herhangi kitaplık veya uygulamayı gelişmeye gerekli bakım artacağına inanıyoruz ediyorum.

Son olarak: OSGi var, oysa Jigsaw henüz mevcut değil ve asla var olmayabilir. OSGi topluluğu, modüler uygulamalar geliştirme konusunda 12 yıllık deneyime sahiptir. Modüler uygulamalar geliştirmekle ciddi olarak ilgileniyorsanız, OSGi şehirdeki tek oyundur.

Çok basit, bugün Java'da gerçek bileşen tabanlı geliştirme yapmak istiyorsanız OSGi şehirdeki tek oyundur.

Bana göre Jigsaw, JDK'da yapılabilecekler ile SUN ve OSGi adamları arasındaki önceki kötü ilişkinin bir kombinasyonudur. Belki Java 8 ile gönderilecektir, ancak bekleyip görmemiz gerekiyor.

Tipik bir kurumsal ortamda çalışıyorsanız OSGi her derde deva değildir ve bir dizi tanınmış kütüphane (size bakarak, Hazırda Bekletme) artık geçerli olmayan sınıf görünürlüğü hakkında varsayımlar yaptığından, sınıf yüklemenin nasıl çalıştığına aşina olmanız gerekecektir. OSGi içinde.

OSGi'yi seviyorum, ancak onu mevcut bir sisteme eklemeye çalışmam. Ayrıca yeşil alan geliştirme açısından artıları ve eksileri tartardım - OSGi için hayatı kolaylaştıran ve hepsini kendi başınıza yapmayan Apache veya Eclipse ürünlerine bakmanızı öneririm.

OSGi yapmıyorsanız, aynı kitaplığın farklı sürümlerine bağımlılıkları olan bir sistemle karşılaşırsanız şansınız kalmaz - tek yapabileceğiniz denemek ve sorunu önlemektir, ancak birden çok sürümüne ihtiyaç duymanıza rağmen kütüphane bana mimari bir 'koku' gibi geliyor.

Mevcut durumu tarif etmek için "köşe vakaları" ifadesini kullanmanıza bayılıyorum.

JAR dosyası spesifikasyonunda, belirli köşe durumlarda ad alanı çözümlemesine ve sınıf yükleme sorunlarına yol açabilecek eksiklikler var

Her neyse, uzun yıllardan beri, onlarsız sonuç olabilecek olandan daha temiz, daha bağımsız, daha tutarlı ve daha sürdürülebilir olan kodların yaratılmasını destekleyen ve daha da iyisi uygulayan araçlar ve tekniklerle ilgileniyorum. Test Driven Design ve Junit böyle bir kombinasyondu.

Kod tabanımızın önemli bir bölümünü OSGi'ye taşımak için birkaç ay harcadıktan sonra, OSGi'nin bu konuda daha da iyi bir araç olduğunu söyleyebilirim. Ve bu gerçekten OSGi'ye geçmek için yeterli bir sebep. Uzun vadede size çok para kazandıracak.

Ve bir bonus olarak, size birçok harika şey yapma şansı verecektir. Bir demo sırasında, OAuth'u desteklemek için kimlik doğrulama modülünü trafik kaybı olmadan sorunsuz bir şekilde yükselttiğinizi hayal edin ... Bir şeyler yaratmak birdenbire bir zevk haline geldi!