Jakarta EE 8: Her şey yeni olmaya devam ediyor – Enterprise Java’nın statükosunda
Jakarta EE’nin ilk sürümü yeni API’ler getirmez, yalnızca zaten orada olanın tamamen satıcıdan bağımsız ve açık bir sürümüdür. Ama perde arkasında çok daha fazlası oldu.
Oracle’ın Java EE’yi açıp Eclipse Foundation’a devrettiği günden neredeyse iki yıl sonra, nihayet 10 Eylül’de zaman geldi: Jakarta EE 8, Jakarta EE 8, Jakarta EE 8, Enterprise Java standardının ilk tamamen açık kaynak versiyonu çıktı.
Bu sürümden ne bekleyebiliriz? Şimdiye kadar Oracle tarafından sürdürülen Java Enterprise Edition 8 ile %100 uyumlu bir sürüm.Bu, iki yıllık sıkı çalışma için fazla bir şey değil, muhtemelen bazı okuyucular şimdiye kadar düşünüyor. Bununla birlikte, bu sürüm, Java Enterprise Edition’ın 20 yıllık tarihindeki en önemli kilometre taşlarından birini temsil etmektedir.Geçen 24 ay boyunca, Eclipse Foundation, Enterprise Java standardının Created’de daha açık ve topluluk odaklı geliştirilmesi için temelleri attı. bulut yönünde -yerli ve böylece zaten beyan edilen ölü standart için bir geleceğe izin verir – ne daha fazla ne daha az.
Jakarte EE ana sayfasında belirgin bir şekilde “Açık Kaynak Bulut Yerel Java: Katılımla desteklenen Jakarta EE, topluluk odaklı işbirliğini ve bulut için açık inovasyonu sağlamaya odaklanıyor.”
Bu bağlamda mevcut sürümde yeni (bulut) API’lerin olmaması elbette biraz şaşırtıcı. Bunun bir nedeni var.
Önce uyumluluk, sonra uzantılar
Jakarta EE’nin ilk çıkışıyla birlikte herhangi bir yenilik yapmayacağı baştan belliydi. İlk adım olarak, Eclipse Foundation’ın yanı sıra Oracle, Fujitsu, IBM, Payara, Red Hat ve Tomitribe’den temsilcilerin yer aldığı Jakarta EE Çalışma Grubu, öncelikle Jakarta EE 8’in eski standartla tamamen uyumlu olmasını sağlamak istedi. Bu, önceki tüm Java EE kullanıcılarının uygulamalarını mümkün olan en az çabayla taşıyabilmelerini ve böylece bugüne kadarki yatırımlarını güvence altına alabilmelerini sağlamanın tek yoludur. Java EE topluluğu içinde kabul için bir zorunluluktur.
Jakarta EE 8 web sitesine bir bakış, bu adımın bile başlı başına önemli bir çaba olduğunu gösteriyor: 60 milyon satırdan fazla kod içeren toplam 43 projenin biraz temizlenmesi için Oracle’dan Eclipse Foundation’a taşınması gerekiyordu. oluşturma ve devreye alma altyapısı ve Git depoları aracılığıyla genel kullanıma sunuldu. API’lerin kendi özellikleri dışında, bu esas olarak TCK’ları etkiler. İşin garibi, %100 uyumluluk sağlamak için tüm hataların ve sorunların ele alınması gerekiyordu.
Bu nedenle, Jakarta EE’nin ilk sürümü yeni API’ler getirmiyor, yalnızca zaten orada olanın açık ve satıcıdan bağımsız bir sürümünü getiriyor, ancak son birkaç yılda perde arkasında çok şey oldu.
perde arkasına bir bakış
Tüm Jakarta EE 8 spesifikasyonları, Java Community Process’in (JCP) halefi olan ve yeni oluşturulan Jakarta EE Spesifikasyon Sürecine (JESP) dayalı olarak açıklanmıştır. Spesifikasyon adları geçişin bir parçası olarak önemli ölçüde standartlaştırılmış ve böylece son yıllardaki yayılma sona ermiş olsa da – örneğin JMS bir hizmettir, JTA ise bir API ve JCA bir mimaridir – spesifikasyonun içeriği uyumludur. Java EE-8 muadilleri ile. Bu, kullanılanların yanı sıra API’ler ve Javadocs için de geçerlidir. javax.*-Ad alanları. Bunun tek istisnası, ticareti yapılan Oracle markalarıdır.
Spesifikasyonun kendisine ek olarak, ilişkili TCK’ler de taşınmış ve Jakarta EE 8 TCK (Eclipse Public License, EPL 2.0) olarak yayınlanmıştır. Bunlar ayrıca Java EE 8 TCK ile uyumludur.
Eclipse GlassFish 5.1 bu yılın başlarında piyasaya sürüldü ve Java EE 8 ile onaylandı. Uygulama sunucusu kaynakları o sırada zaten Eclipse Foundation’da olsa da, Oracle altyapısı üzerinde testler hâlâ devam ediyordu. Jakarta EE 8’in piyasaya sürülmesiyle eş zamanlı olarak Eclipse GlassFish 5.1, TCK’leri kendi altyapısında çalıştırdı ve bu nedenle yalnızca Java EE 8 ile değil, Jakarta EE 8 (tam platform ve web profili) ile de uyumludur. Halihazırda uyumlu olan tüm sunucuların bir listesi “Jakarta EE 8 Uyumlu Ürünler” altında bulunabilir.
Gelecek ne gösterir?
Tabii ki, son iki yıldaki tüm çabalar ancak Eclipse Vakfı’nın gelecek vizyonları gerçekten gerçekleştiği takdirde meyvesini verecektir. Geri Çağırma: “Açık Kaynak Bulut Yerel Java”. Açık kaynak kuruluşuna göre, gelecekte yeni sürümleri çok daha hızlı ve daha düzenli bir şekilde yayınlamak istiyorlar. Yine Eclipse Foundation’ın bir parçası olan JDK veya MicroProfiles’in sürüm döngülerine bakarsanız, bu çok gerçekçi bir hedef gibi görünüyor.
Ek olarak, giriş engeli önemli ölçüde azaltılacaktır. Bu, hem uygulama sunucusu üreticileri hem de yeni standardı tanıtmak isteyen şirketler, gruplar veya bireyler için geçerlidir. Bu yöndeki ilk önemli adım, TCK’ların açılması ve yeni doğan Jakarta EE Spesifikasyon Süreci sayesinde şimdiden atıldı.
Kendi ifadelerine göre, gelecekte esas olarak “Önce Kod” yaklaşımına göre yeni spesifikasyonlar oluşturulacak. Bu, API’lerin bir spesifikasyona dahil edilmeden önce pratikte kurulması gerektiği anlamına gelir. J2EE dünyasından – ve ayrıca Java EE dünyasından – çok iyi bilinen fildişi kule API’lerine karşı koruma sağlaması ve ayrıca yeni API’ler için topluluk kabulünü kesinlikle artırması amaçlanan açık kaynak topluluğunda yaygın bir uygulama.
Bir topluluk anketi, mikro hizmetler, Kubernet’ler ve hizmet ağları (özellikle Istio) gibi bulutta yerel konuların Jakarta EE’nin gelecekteki başarısı için kritik öneme sahip olacağını ve bu nedenle yeni spesifikasyonlar için başlıca adaylar olduğunu gösterdi. Özellikle mikro hizmetlerin desteklenmesiyle ilgili olarak, yeni API’lerin belirtilmesine ek olarak, MicroProfile.io’ya daha yakın olacağı varsayılabilir. Bu, Jakarta EE 8 ve MicroProfile 3’ün ortak kullanımına değinen bir dizi sunumun yer aldığı Jakarta EE’nin yayınlanmasıyla paralel olarak düzenlenen JakartaOne çevrimiçi konferansının gündemi tarafından da önerilmektedir.
Markalarla ilgili sorun
Ancak sonraki adımları atmadan önce “küçük” bir sorunu çözmemiz gerekiyor: tüm Java API paketlerini şu adresten yeniden adlandırın: javax.* ile jakarta.*. Oracle ayrıca paket ön ekini kullanmasına rağmen javax izin verilir, ancak yalnızca API’ler değişmeden kalırsa. Mevcut API’lerde yapılan yeni API’ler veya değişiklikler (bu arada, hata düzeltmeleri için de geçerlidir) otomatik olarak kullanım yasağıyla sonuçlanır. javax.
Gelecekte bir API’ye dokunulduğunda her zaman yeniden adlandırılıp adlandırılmayacağı veya alternatif olarak tüm paketlerin bir kez yeniden düzenlenmesi gerekip gerekmediğine dair bir tartışma, Büyük Patlama’ya doğru açık bir eğilim gösterdi. Ayrıca, sadece bir takas kabul edildi javax.* ile jakarta.* yer almalıdır, ancak önekten sonra başka değişiklik yapılmamalıdır.
Sonuç olarak, şu anda yaklaşan Jakarta EE 9 sürümünün henüz herhangi bir yeni API getirmeyeceği, yalnızca yeni paket yapılarını uygulayacağı görülüyor. Gelecekte Jakarta EE 9 sunucularında çalışmak isteyen mevcut uygulamaların buna göre dönüştürülmesi gerekecektir. IDE yeniden düzenleme araçları burada yardımcı olabilir. Alternatif olarak, uygulama sunucuları eski paket adlarını yenileriyle dahili olarak eşleyebilir, böylece mevcut Jakarta 8 uygulamaları da herhangi bir çaba sarf etmeden Jakarta 9+ üzerinde çalışabilir. Uygulama sunucularının bugün zaten işlettiği tüm vudu dışında, gerçek bir büyücülük yok.
Yenilikler – sadece ne zaman?
GlassFish, OpenLiberty (IBM) ve WildFly’den (Red Hat) sonra diğer Java EE 8 uygulama sunucularının da Jakarta TCK’ler aracılığıyla çalışacağı ve bu nedenle kendilerini Jakarta EE ile uyumlu olarak adlandırabilecekleri varsayılabilir. Oracle ayrıca, hem Java EE 8 hem de Jakarta EE 8 ile uyumlu bir WebLogic Uygulama Sunucusu sürümü üzerinde sıkı çalıştığını duyurdu.
“Jakarta EE 8’in piyasaya sürülmesinden son derece memnunuz. Bu, Oracle da dahil olmak üzere tüm Jakarta EE topluluğu tarafından yapılan büyük bir çalışmanın doruk noktasını temsil ediyor ve herkesin katkılarını takdir ediyoruz. Oracle, bir Java EE 8 sunmak için çalışıyor ve Jakarta EE 8 ile uyumlu WebLogic Sunucu uygulaması…,” dedi Oracle Yazılım Geliştirme Başkan Yardımcısı Tom Snyder.
Yerel bulutta ilk gerçek atılımlar muhtemelen yalnızca Jakarta EE 10 ile beklenebilir. JCP günlerinde, beş ila on yıl sürerdi. Umarım, Eclipse Vakfı bunu onda bir sürede yapabilir. Jakarta EE uygulamalarında satıcıdan bağımsız bağlantı ve NoSQL veritabanlarının kullanımı için yeni bir API için ideal bir ilk aday Jakarta NoSQL’dir.
Çözüm
Heyecanlı zamanlar bizi bekliyor. Enterprise Java standardının geleceğine karar verecek zamanlar. Eclipse Foundation (MicroProfile.io’nun bir parçası olarak) ve Enterprise Java topluluğu ile olan kişisel deneyimlerime dayanarak, bu zamanların iyi geçeceğinden eminim.
()
ana sayfaya