Jakarta EE: Sonun Başlangıcı mı yoksa Yeni Bir Başlangıç Şansı mı?
Eclipse Foundation’ın yönetici direktörü Mike Milinkovich, Eclipse Foundation ile Oracle arasında Jakarta EE ve Oracle’ın Java ticari marka haklarının kullanımına ilişkin 18 aydan uzun süredir devam eden müzakereler hakkında ciddi bir güncelleme yayınladı. Resmi olarak, bu, ad alanı da dahil olmak üzere adlandırma haklarını kullanma hakkıdır. javax. Gayri resmi olarak bu, Enterprise Java standardının geleceğinden başka bir şey değildir: Jakarta EE (eski adıyla Java EE).
Yaklaşık bir buçuk yıl önce Oracle, Java EE’nin açıldığını duyurdu ve kısa bir süre sonra Teknoloji Uyumluluk Kitleri (TCK’ler) dahil olmak üzere ilişkili kaynakları Eclipse Foundation’a devretti. Önümüzdeki birkaç ay boyunca açık kaynak kuruluşu, mevcut Java EE sürüm 8’i %100 uyumlu Jakarta EE 8’e taşımak için çok fazla zaman ve enerji harcadı.
Bu çabalara paralel olarak, Oracle’ın şimdiye kadar yürürlükte olan Java Topluluk Sürecinin (JCP) yerini alması amaçlanan Jakarta EE Spesifikasyon Süreci (JESP) adı verilen ayrı bir spesifikasyon süreci oluşturuldu. Ian Robinson ve Kevin Sutter tarafından yazılan “Jakarta EE indi” blog yazısında okunabileceği gibi, bağlantı noktası artık tamamlandı.
Görünürde anlaşma yok
Başlangıçta, Oracle’ın Eclipse Vakfı’na yaptığı “bağıştan” sonra, ticari markalar ve ilgili adların haklarının kullanılması konusunda da önemli bir anlaşmaya varılabileceği görüldükten sonra, Milinkovich şimdi bunun ne yazık ki öngörülemez olduğunu yazıyor:
“Javax paketi ad alanının Jakarta EE spesifikasyonuna dönüşmesine izin verecek şartlar üzerinde anlaşmak Eclipse Foundation ve Oracle’ın karşılıklı niyetiydi. Ne yazık ki, aylarca süren iyi niyetli müzakerelerin ardından, Eclipse Foundation ve Oracle bunu başaramadı. Eclipse Foundation topluluğunun javax paketi ad alanını değiştirmesi veya şu anda Java EE spesifikasyonunda kullanılan Java ticari markalarını kullanması için yapılan bir anlaşmanın şartlarını kabul edin. Bunun yerine Eclipse ve Oracle, javax paketi ad alanının Jakarta EE topluluğu tarafından geliştirilemeyeceği konusunda anlaştılar. Ayrıca, mevcut belirtim adları gibi Java ticari markaları, Jakarta EE belirtimi tarafından kullanılamaz.”
Eclipse Foundation, Java EE kökenlerini taşırken, Oracle ile yapılan ilk görüşmelerden sonra başlangıçta, ad alanındaki mevcut API’lerin javax orada yeniden kullanıldı ve bir dereceye kadar değiştirildi. Ancak, yeni belirtim yeni ad alanını kullanmalıdır. cakarta tanıştırılmak. Böyle bir yaklaşımla, mevcut Java EE uygulamalarının geriye dönük uyumluluğu sağlanırken, platformun daha fazla kademeli olarak geliştirilmesi sorunsuz bir şekilde mümkün olacaktır. Binlerce uygulama ile son 20 yılda büyüyen ekosistem göz önüne alındığında, Enterprise Java standardının geleceği için temel bir ön koşul.
Ancak, Eclipse Foundation ve Oracle arasındaki müzakerelerin mevcut durumu tam da bunu yasaklıyor. javax Onlara izin verilmiyor. Herhangi bir değişiklik yapılırsa, paketin ve ilişkili API’nin de yeniden adlandırılması gerekir. Ve bu yeterli değilmiş gibi, görevdeki kişi spesifikasyonlarda olmaya devam edecek javaxad alanı, bu arada Oracle lisanslı bir çalışma zamanının varlığını bekleyen Oracle’ın önceki sürümleri: Milinkovich:
“Yukarıdakilere ek olarak, javax ad alanını kullanan tüm belirtimler, Java EE’nin geçmişte sahip olduğu kapsayıcı ve sertifika gerekliliklerini taşımaya devam edecektir. Örneğin, javax ad alanını kullanan Jakarta EE belirtiminin herhangi bir sürümüyle uyumlu olduğunu iddia eden uygulamalar, Oracle’dan lisanslanan sertifikalı Java SE uygulamalarını içeren kapsayıcıları test etmeli ve dağıtmalıdır. Bu kısıtlamalar, javax’ı kaldıran gelecekteki platform spesifikasyonu revizyonları da dahil olmak üzere, javax kullanmayan Jakarta EE spesifikasyonları için geçerli değildir.
Milinkovich’e göre müzakereler, her iki taraf için de mümkün olan en iyi sonucun elde edildiği bir duruma ulaştı. Başka bir deyişle, Oracle’dan daha fazla ödün verilmesi beklenemez.
Sorun nerede?
Ama bu bir sorun mu? Eclipse Foundation’ın, Java EE 8’den Jakarta 8’e taşıma durumunda olduğu gibi, başlangıçta mevcut API’lerde değişiklik yapmadığını ve bu nedenle, belirtimler ve TCK’ler dahil olmak üzere mevcut yapıları koruyabildiğini varsayalım. Her şeyden önce, yalnızca Çalışma Zamanı ile ilgili sorun kalır. Bu da, yine Eclipse Vakfı’nın tüzüğüne karşı, diğer satıcılara göre özel bir satıcıyı, yani Oracle’ı tercih edecektir.
Şu anda biri ya da diğeri düşünüyor olabilir. İstisnai durumlarda, kesinlikle kendi gölgenizin üzerinden atlayabilirsiniz. Sonuçta kaynakların şu anki durumunu Oracle’a borçluyuz. Ancak, o kadar basit değil. Eclipse Vakfı için, şimdiye kadar çokça başvurulan üretici tarafsızlığının seçici bir şekilde terk edilmesi, en kötü durumda, hayır kurumu statüsünün ve ilgili vergi indirimlerinin bir kısmını kaybedeceği ve bu nedenle artık kendi masrafını karşılayamayacağı anlamına gelebilir. Kuruluş için bu sadece bir ticari marka ve isim hakları meselesi değil, daha çok varoluşsal bir meseledir ve bu nedenle Oracle ile buna karşılık gelen bir uzlaşma tanım gereği mümkün değildir.
Jakarta EE 8’den sonra ne geliyor?
Ama o zaman alternatif nasıl görünürdü? Gerçekçi olmak gerekirse, Jakarta EE 8’den sonraki tüm sürümler için Eclipse Foundation’ın tek seçeneği, tüm paketleri şu adresten indirmektir: javax sonrasında cakarta limanda. Ve bunu mümkün olan en kısa sürede, platformun uzun süredir gecikmiş daha fazla geliştirilmesi ve bunun sonucunda ortaya çıkan yenilikler olmadan yapmak istemiyorsanız. Doğal olarak, tüm spesifikasyonların ve ilgili TCK’lerin de uyarlanması veya yeniden yazılması gerekecektir.
Sıfırdan başlayan projeler için bu kesinlikle sorun olmaz. Öte yandan, son 20 yılda ortaya çıkan birçok mevcut iş uygulaması için durum farklıdır. Halihazırda var olduğunu umduğumuz testler de dahil olmak üzere kodunuz üzerinde gerekli yeniden düzenlemeleri yapmaya istekli olsanız bile, yeni standartla henüz uyumlu olmayan tescilli uygulama sunucusu kitaplıklarına, çerçevelerine ve uzantılarına güvenmeniz çok olasıdır. Kaos kaçınılmaz görünüyor.
Standarda bağlı kalmak hala mantıklı mı? O zaman ne katma değeri olurdu? Tüm uygulama sunucusu satıcılarının üzerlerine düşeni yapmaya devam etmesi koşuluyla, satıcı bağımsızlığı büyük bir artı olacaktır. Farklı uygulamalar arasında uyumluluğu sağlayan bağımsız TCK’ler olmaya devam edecektir.
Hafife alınmaması gereken bir diğer avantaj da spesifikasyon sürecidir (JESP uzantısıÇok çeşitli ilgi gruplarının katılımı, standardın gelecekteki gelişiminin yalnızca tek bir üreticinin çıkarlarına göre yönlendirilmemesini sağlar. Ama tam tersine. Eclipse Vakfı’nın MicroProfile projesinin son gelişimini örnek alırsanız, bunun gelecekte ne kadar hızlı ve topluluk odaklı olabileceğine dair bir fikriniz var.
Hâlâ geriye dönük uyumluluk sorunuyla karşı karşıyayız. David Blevins’in (Tomitribe’nin kurucusu ve CEO’su) “Jakarta EE: A New Hope” adlı blog yazısında “Geriye dönük uyumluluk mümkün” bölümünde açıkladığı gibi, kesinlikle tatsız bir sorun, ancak çözülemez değil. Uygulama sunucuları, bugün zaten yaptıklarını yapmalı ve bayt kodu oluşturma ve/veya manipülasyon kullanarak eski Java EE kaynaklarını Jakarta EE’nin harika yeni dünyası için hazırlamalıdır. Blevin:
“Jakarta EE uygulamasının bayt kodunuzu javax’tan taşıması için Cakarta’da “aynısından daha fazlası”. Bazı zorluklar olacak, ama sonunda her şey nasılsa öyle oluyor.”
David’in haklı olduğunu ve uygulama sunucusu satıcılarının bu adımı atmaya istekli olduğunu umalım. Eğer öyleyse, Jakarta EE’nin bir kurumsal Java standardı olarak geleceğinin önünde hiçbir şey duramaz. Değilse, Jakarta EE gelecekte birçok kurumsal Java çerçevesinden yalnızca biri olacaktır.
()
Haberin Sonu