Jakarta EE 8: Her şey yeni kalır – Enterprise Java'nın statükosu için
Jakarta EE'nin ilk versiyonu yeni arılar getirmiyor, ancak zaten orada olanın tamamen nötr ve açık bir versiyonu getiriyor. Perde arkasında çok daha fazlası oldu.
Neredeyse tam olarak iki yıl, Oracle Java EE açıldıktan ve Eclipse Vakfı'na teslim edildikten sonra, nihayet 10 Eylül'ün zamanıydı: Enterprise-Java standartlarının ilk tam açık kaynak varyantı Jakarta EE 8 yayınlandı.
Bu sürümden ne bekleyebiliriz? Daha önce Oracle'ın bakımı altında olan Java Enterprise Edition 8'in % 100 uyumlu bir versiyonu. Bu iki yıllık sıkı çalışma için çok fazla değil. Bununla birlikte, bu sürüm Java Enterprise Edition'ın 20 yıllık tarihindeki en önemli kilometre taşlarından birini temsil etmektedir. Son 24 ay boyunca, Eclipse Vakfı'nda daha fazla açık geliştirmenin temeli ve Enterprise-Java standart topluluğu tarafından yönetildi ve bu nedenle zaten ölmüş olan standart için bir geleceğe izin verdi.
“Yerli Java: Katılım tarafından desteklenen Jakarta EE, toplumun liderliğindeki işbirliğinin kalifikasyonuna ve bulut için açık yeniliğe odaklanıyor, sonuç olarak Jakarte EE'nin ilk sayfasında öne çıkıyor.
Bu bağlamda, elbette, mevcut sürümde yeni arıların (bulut) olmadığı konusunda biraz şaşırıyor. Bir sebep var.
İlk uyumluluk, sonra uzantılar
Çok yakında Jakarta EE'nin ilk sürümünde hiçbir yeniliği olmayacağı açıktı. İlk adımda, Jakarta EE'nin Eclipse Vakfı'na ek olarak, Oracle, Fujitsu, IBM, Payara, Red Hat ve Tomribute temsilcilerinin Jakarta EE 8'in önceki standartla tamamen uyumlu olduğunu keşfetmek istediği çalışma grubu. Bu, önceki tüm Java EE kullanıcılarının uygulamalarını mümkün olan en az çaba ile göç etmesini ve dolayısıyla şimdiye kadar yapılan yatırımlarının garanti etmesini sağlamanın tek yoludur. Java EE topluluğunda kabul için bir zorunluluktur.
Bu adımın tek başına önemli bir çabaya eşdeğer olması, Jakarta EE 8'e bir bakış gösteriyor. Oracle'dan orada yeniden düzenlenecek tutulma temeline geçecek 60 milyondan fazla kod çizgisine sahip toplam 43 proje, yapılarına ve mevduatlarına dahil edilecek. API'nın kendisinin özelliklerine ek olarak, bu TCK'yı etkiler. Garip bir şekilde, %100 uyumluluk sağlamak için tüm hatalar veya problemler tespit edilmelidir.
Jakarta EE'nin ilk versiyonu yanında yeni bir arılar getirmiyor, ancak zaten orada olanın tamamen nötr ve açık bir versiyonu, ancak son iki yılda perde arkasında çok daha fazla oldu.
Perde'nin arkasına bir bakış
Jakarta-ee 8'in tüm özellikleri, Java Topluluğu Sürecinin (JCP) halefi olan yakın zamanda oluşturulan Jakarta EE (JESP) spesifikasyon sürecine uygun olarak açıklanmıştır. Her ne kadar spesifikasyonların isimleri göç bağlamında önemli ölçüde standartlaştırılmış olsa da ve bu nedenle son yılların vahşi büyümesi, örneğin, JTA, JTA, bir API ve JCA'nın bir mimarlıktır. Bu hem arılar hem de javadoclar için de geçerlidir. Javax.*-NAPEES. Tek istisna, değiş tokuş edilen Oracle markalarıdır.
Spesifikasyonların kendilerine ek olarak, ilişkili TCK'lar TCK Jakarta EE 8 (Eclipse Public Lisans, EPL 2.0) gibi taşınmış ve yayınlanmıştır. Bunlar ayrıca Java EE 8 TCK ile uyumludur.
Yılın başında, Eclipse Glassfish 5.1 Java EE 8 ile yayınlandı ve sertifikalandırıldı. Uygulama sunucusunun kaynakları o anda Eclipse Vakfı'ndayken, testler hala Oracle'ın altyapısındaydı. Jakarta EE 8'in yayınlanmasıyla aynı zamanda, Eclipse Glassfish 5.1 ayrıca TCK'yı altyapısından geçti ve bu nedenle Java-ee-8- olarak değil, aynı zamanda bir Jakarta-ee-edummente (tam platform ve web profili) olarak kabul ediliyor. Tüm uyumlu sunucuların bir listesi “Jakarta EE 8 uyumlu ürünler” de bulunabilir.
Gelecek ne getiriyor?
Tabii ki, son iki yılın tüm çabaları ancak Eclipse Vakfı'nın gelecekteki vizyonları da yapılırsa geri ödenir. Hatırlıyoruz: “Açık Kaynak Bulutu Java Yerli”. Açık kaynak organizasyonuna göre, gelecekte çok daha hızlı ve daha düzenli yeni sürümler yayınlamak istersiniz. Başlangıçta Eclipse Foundation'dan da JDK veya Micro -Profilo'nun sürüm döngülerine bir göz atarsanız, bu çok gerçekçi bir hedef gibi görünüyor.
Ayrıca, giriş engelini önemli ölçüde azaltmak istiyorsunuz. Bu, uygulama sunucularının aplikatörlerinin yanı sıra yeni standardı ilerletmek isteyen şirketler, gruplar veya kişiler için de geçerlidir. TCK'yı açarak ve Jakarta EE'nin yeni yarattığı Speimo süreci sayesinde önemli bir ilk adım atıldı.
Bildirimlerine göre, gelecekte esas olarak “ilk kod” yaklaşımına dayanarak yeni özellikler oluşturulmalıdır. Bu, arıların önce belirli bir içine dökülmeden önce pratikte yerleşmeleri gerektiği anlamına gelir. Açık kaynak topluluğunda, sadece J2EE dünyası tarafından tasarlanan ve bazen Java-ee dünyası tarafından tasarlanan tanınmış fildişi kulesinin arılarını koruması ve yeni arılar için toplulukta kabulü kesinlikle artırması gereken yaygın bir uygulama.
Topluluktaki bir anket, mikro hizmetler, kubernetes ve hizmetlerin (özellikle histio) gibi bulut yerel argümanlarının Jakarta EE'nin gelecekteki başarısı için kritik olacağını ve bu nedenle yeni özellikler için en iyi adaylar olduğunu göstermiştir. Mikro hizmetlerin desteği ile ilgili olarak, yeni arıların spesifikasyonlarına ek olarak, mikroprofil için daha güçlü bir yaklaşımın gerçekleşeceği varsayılabilir. Bu, Jakarta EE'nin piyasaya sürülmesine paralel olan Jakartoone Çevrimiçi Konferansı'nın gündemiyle de önerilmektedir.
Markalarla ilgili sorun
Bununla birlikte, bir sonraki adımlar atılmadan önce, dünyadan “küçük” bir sorun yaratılmalıdır: Javax.* İLE Jakarta.*. Oracle, paketin paketini daha da kullanıyor Javax İzin verildi, ancak sadece arılar değişmeden kalırsa. Mevcut arılardaki yeni arılar veya değişiklikler (bu hata düzeltmeleri için de geçerlidir), aynı zamanda otomatik olarak kullanımının yasaklanmasına yol açar. Javax.
Bir API'ya dokunulduğunda veya alternatif olarak, tüm paketlerin bir kez yeniden yapılandırılması gerektiğinde, her zaman gelecekte yeniden adlandırılması gerektiği konusunda bir tartışma, büyük patlamaya karşı açık bir eğilim göstermiştir. Ayrıca, sadece bir değişim Javax.* İLE Jakarta.* Bu gerçekleşmelidir, ancak önekin arkasında daha fazla değişiklikten kaçınılmalıdır.
Sonuç olarak, şu anda bir sonraki Jakarta EE 9 sürümünün henüz yeni arılar getirmeyeceği, ancak sadece paketin yeni yapılarını oluşturacağı anlaşılıyor. Jakarta EE 9 sunucularında çalıştırmak isteyen mevcut uygulamalar buna göre değiştirilmelidir. IDES yeniden düzenleme araçları yardımcı olabilir. Alternatif olarak, Applications Server, paketlerin yeni klasörlerde dahili olarak eski adları olabilir, böylece mevcut Jakarta-8 uygulamaları Jakarta 9+ üzerinde herhangi bir çaba sarf etmeden gerçekleştirilebilir. Tüm Voodoo'ya ek olarak, uygulama sunucusu bugün çalışıyor, gerçek füze bilimi yok.
Yenilikler – sadece ne zaman?
Buna ek olarak, Glassfish, Openliberty (IBM) ve Wildfly (Red Hat) 'a göre, diğer Java-e-ee-ee-ee-ee-8 uygulama sunucularının da Jakarta'nın TCK'sını geçebileceği ve bu nedenle kendilerini Jakarta -ed-Friendly'de tanımlayabileceği varsayılabilir. Oracle bile, Java EE 8 ve Jakarta EE 8 ile aynı anda WebLogic uygulama sunucusunun uyumlu bir versiyonu üzerinde yüksek baskı ile çalıştığınızı duyurdu.
“Jakarta EE 8'in piyasaya sürülmesi son derece mutluyuz. Bu, Oracle dahil Jakarta EE topluluğu tarafından büyük bir çalışmanın doruk noktasını yeniden yazdırıyor ve katkıları takdir ediyoruz. Oracle, bir Java EE 8 ve 8 yazılımı ve Jakarta EE 8 uyumlu webojik uygulama …” diyor Tom Snyder.
Bulutun yerlisi yönündeki ilk gerçek yenilikler muhtemelen sadece Jakarta EE 10 ile öngörülebilir. JCP'ler zamanında 5 ila on yıl arasında olacak. Umarım Eclipse Vakfı bunu zamanın onda biri kadar yapacaktır. Yeni bir arılar için ilk sıcak aday, üreticiden bağımsız olarak bağlantı için Jakarta Nena ve Jakarta EE uygulamalarında veritabanı Nena kullanımıdır.
Çözüm
Heyecan verici zamanlar bize doğru geliyor. Kurumsal Java standardının geleceğine karar verecek zamanlar. Eclipse Vakfı (Microprofile.io'nun bir parçası olarak) ve Enterprise-Java topluluğuyla ilgili kişisel deneyimimde, umarım bu zamanlar olumludur.
()