Java modülerleştirme: ikinci ve son deneme?
Geçen hafta yine oldu. Mark Reinhold’dan isimsiz bir e-posta, OpenJDK bulmaca geliştirici posta listesi aracılığıyla geldi. Şimdi yeni bir Jigsaw prototipi olacaktı. Daha kolay bir girişim olmalı. Sıkı bir “Marka” ile imzalanan neredeyse 18 satır saf hayal kırıklığı.
Bir süredir Jigsaw, Java için modüler bir sistem sunma girişimi olmuştur. 2005’te JSR 277 (Java Modularity) ile Java 7 için planlanan ve uzun süredir Java 8 için planlanan şey, ancak geçen yıl süresiz olarak ertelendi. Peki neden modüler bir sisteme ihtiyacınız var?
Jigsaw, Java uygulamaları için modüler bir sistem olmanın yanı sıra modüler bir Java platformunu da taşıyabileceğini iddia ediyor. Bu modüler Java, daha sonra hem tam sunucuları hem de yalın donanımı destekleyen hemen hemen her türlü yapılandırmayı sağlayabilir. Java yükleyicilerinin saf boyutuna ek olarak (Java 7u25 için 35 ve 51 MB arasında), böyle bir yapı ayrıca gerekli kitaplıkların modüler olarak yüklenmesine izin verir ve sonuç olarak muhtemelen çalışma zamanı hızını da önemli ölçüde artırır.
Mark Reinhold ve Yapboz 2011 (Fotoğraf: M.Eisele)
Pek çok kişi Oracle’ın JVM’yi mobil cihazlar için uygun hale getirme konusundaki tek motivasyonunun son iki noktanın hemen arkasında olduğunu düşünüyor. Son yıllarda, Java’nın iOS veya Android’de nasıl görünebileceğini etkileyici bir şekilde gösteren prototipler her zaman olmuştur. Şimdiye kadarki prototipler muhtemelen JVM’nin yalnızca yeterli bölümünün tam bağlantı noktalarını temel almış olsa da, modülerleştirilmiş bir Java platformunun faydası burada hızla ortaya çıkıyor.
Riddler ile ilgili sorunlar
Aslında, sürekli kaymalar ve yön değişiklikleri, Java geliştirmenin uzun süredir yoldaşları için şaşırtıcı değil.
“Sun’da yetersiz bir şekilde başladı, Oracle’a entegrasyondan zar zor kurtuldu, personeli ancak yaklaşık bir yıl önce tamamladı…” (@mreinhold, kaynak: twitter)
Temmuz 2012 gibi geç bir tarihte, son büyük değişiklik sırasında, gerçek arka plan Mark’ın Twitter akışında okunabiliyordu. Proje çok bilinmesine rağmen Oracle bünyesinde ve Sun öncesi destek neredeyse yok denecek kadar az sayılabilecek geliştirme yetenekleri Jigsaw için istenilen ölçüde kullanılamadığı için Java’da da çok sayıda güvenlik sorunu var. . Bu sorunun dışında, önceki prototipler, tam modülerleştirmenin önceki dil sürümleriyle bazı ciddi uyumsuzluklara yol açacağını göstermiştir. Açıkçası, insanlar bu adımı atmaya isteksiz. Java’nın neredeyse tam geriye dönük uyumluluğu bir başarı öyküsü olduğundan, bu çekince anlaşılabilir. Ayrıca derleme zamanı modülerleştirmesinin uzun süredir Maven, Ivy, Gradle ve Co. gibi araçlar tarafından sağlandığı göz önüne alındığında.
Modüler Java’ya gerçekten kimin ihtiyacı var?
Bu noktada, Java 8’in yerine sunulan Kompakt Profiller (JEP 161), önceki hikayeye çok iyi uyuyor. Özel uygulama alanlarına yönelik daha yalın JRE’lere yönelik arzuyu karşılamak için, tüm platformun işlevlerinin yalnızca bir alt kümesini içerecek üç kompakt profil belirlenmiştir. Ne yazık ki, yalnızca daha önce Java ME’ye dayalı geliştirmeler onunla hizmet etti. Bu, çalışma zamanı ortamının kendisinin çok daha yalın sürümlerde (muhtemelen 10 MB’tan az) mevcut olacağı anlamına gelir. Yakın zamanda tanıtılan JRE sunucusunun da profillerle aynı şekilde oluşturulup oluşturulmadığı bilinmiyor. Ancak bu durumda bile, uzmanlaşmış JRE’lerin türü ve sayısının artmaya devam edeceği açıktır.
Java uygulamaları için modüler bir sisteme sahip olma iddiası çözümlenmemiştir. OSGi, JBoss modülleri veya diğer OSGi tabanlı basitleştirmelere benzer bir şey. Böyle bir yaklaşımdan yalnızca Java SE uygulamaları değil, aynı zamanda Java EE gibi Java SE tabanlı platformlar da yararlanır. Modüler bir sistemi standardize etme ihtiyacı tam olarak burada ortaya çıkıyor. Çoğu sunucu bugün zaten OSGi’yi dahili olarak kullansa bile, tüm avantajlarıyla birlikte böyle bir modüler sistemin uygulama geliştiricilerin ellerine teslim edilip edilmeyeceğine ve nasıl sunulacağına üreticiler karar verir. Ve tabii ki, özellikle standardizasyon eksikliği bağlamında, kolayca aktarılamayan çeşitli çözüm yaklaşımları da vardır. İçerik açısından, OSGi savunucuları haklı olarak, yaklaşımlarının uzun yıllardır kurulup test edildiğine ve standardizasyon çabalarının giderek şirket özelliklerini içerdiğine işaret ediyor.
Java hiçbir zaman modüler bir sisteme sahip olmaz
Açıklanan tüm problemler ve yan etkiler açıkça tek bir sonuca yol açacaktır: Java asla gerçek bir modüler sisteme sahip olmayacaktır. Oracle söz konusu olduğunda, asıl hedefe profillerle çoktan ulaşıldı. Modülerleştirmeyi daha fazla ele alma ihtiyacı bu nedenle muhtemelen geçersizdir. Uygulama geliştirme söz konusu olduğunda, derleme zamanı modülerleştirme ile OSGi arasındaki boşluğun orta vadede kapanması umulmaktadır. OSGi Alliance bunda önemli bir rol oynuyor. OSGi’nin rakiplerinin itibarını ciddiye almalı ve en azından tutarlı basitleştirme yoluyla sık sık eleştirilen karmaşıklığı akıllıca gizlemelidir. Ne yazık ki, OSGi diğer Java platformları için cevap değil. OSGi spesifikasyonu JCP’nin bir parçası olmadığından, bu bağımlılığı tanımlayan bir platformun olasılığı sıfırdır. Bu nedenle, sunucularda renkli bir karmaşa olmaya devam edecek ve bu nedenle modülerlik, yeni işlevsel kapsamlar için bir argüman olmayacaktır. Bu özellikle Java EE için talihsiz bir durumdur.
Ayrıca bakınız:
- Java Modülerleştirme: Başa Dön!; Haberler hakkında Haberler geliştiricisi
()
Haberin Sonu