Altı ayda bir güncelleme: Mevcut Java Serbest Bırakma Trenine Yol

Portakalkafa

Global Mod
Global Mod


  1. Altı ayda bir güncelleme: Mevcut Java Serbest Bırakma Trenine Yol

Java 9'un 2017'de piyasaya sürülmesi, Java platformunun yeni sürümleri çok daha iyi tanımlanmış yeni bir sürüm treniyle yayınladı. Ne yazık ki, serbest bırakma trenindeki çeşitli değişiklikler ve iyileştirmeler hakkındaki beyanlar genellikle çok belirsizdi ve toplulukta yanlış öğeler bile vardı. Özellikle Oracle burada az baskı işi sundu ve yeni sürüm treni olması gerektiği gibi şeffaf ve temiz bir şekilde tanımlamadı. Java 17'nin piyasaya sürülmesinin piyasaya sürülme treninde tekrar değiştiğinden, bu yazıyı belirli süreci tanımlamak için kullanmak istiyorum.








Hendrik Advers (@hendrikebbers), JCP uzman grubunun bir üyesi olan Java'nın şampiyonu ve farklı Javaone rock yıldızı hoparlörleri aldı. Kendi açık unsurları şirketi ile Hendrik şu anda Hedera Hashgraph'ı tasarlamaya ve hizmetlerini halka açık hale getirmeye yardımcı oluyor. Hendrik aynı zamanda Juug Dortmund ve Cyberland tarafından ve tüm dünyada Java teması hakkında dersler ve seminerler düzenliyor. “Mastering JavaFx 8 Controls” adlı kitabı 2014 yılında Oracle Press tarafından yayınlandı. Hendrik, TSC Emptopenjdk ve Eclipse WG benimseyenlerin bir üyesidir.







Güzel Eski Dünya


Ancak yeni sürüm trenine bakmadan önce, eski Java sürümlerinin sürümlerine bakmak mantıklı. Aşağıdaki diyagram, Java 6, 7 ve 8'in ömrünün sürüm süresini ve süresini göstermektedir. Sürümlerin yaşam döngüsü, ilgili sürümün ücretsiz güvenlik güncellemelerinin kullanılabilirliği ile tanımlanır. Sürümlerden biri için daha fazla ücretsiz güncelleme yapılmaz olmaz, süreleri diyagramda sona erer.








Diyagramda farklı noktalar görülebilir. Güvenlik güncellemeleri olan en az iki sürümün hala desteklendiği bir dönem olduğu an için önemlidir. Bu kez, uygulamalarını Java'nın en son sürümünde taşımak için platform kullanıcılarına bir süre olarak ihtiyacınız var. Ayrıca, yeni sürümlerin sürümlerinin mesafeleri farklıdır. Bunun nedeni, bu Java sürümlerinin kendi sürümleri için tanımlanan tüm özellikler uygulandığı anda yayınlanmasıdır.

Bu eski Java sürümlerinin her biri için özellikler, Java Topluluğu Sürecinde (JCP) Java (JSR) şartnamesi isteği dahilinde tanımlanmıştır. Java 8 için, örneğin, Bölüm 3'teki JSR 337'de bireysel özelliklerin bir listesi bulunabilir. Bunlar JSR olarak da belirtilmiştir, bunun için JSR 335'teki Java'daki lambda ifadelerinin ve JSR 310'daki API verileri ve süresi tanımlanmıştır.

Yeni bir Java sürümünde hangi JSRS'nin uygulanması gerektiği önceden tanımlandığından, sürüm süresi asla tanımlanamaz. Bu, sürümlerin yayınları arasında uzun sürelere yol açtı.

Tüm süreçte, bu sürümlerin, örneğin Oracle JDK için belirli sürümler olmadığını belirtmek hala önemlidir. Tüm bu sürümler OpenJDK'da oluşturulmuştur. Bu nedenle, her Java tedarikçisi, işlevsellik farklılıkları olmadan mevcut sürümle çalışma zamanının bir yapısını sunabilir.

Daha hızlı sürümler aracılığıyla daha dinamik


Ancak Java 9 ile bu prosedür önemli ölçüde değişmiştir. Belirsiz bir görünüm ve yaşam döngüsü ile uzun süreli sürümler yerine, Java platformunun yeni büyük bir sürümü altı ayda bir görünür. Bu daha önce OpenJDK'da olduğu gibi olur, ancak OpenJDK kaynakları tamamen daha iyi iş akışlarını anlayabileceğiniz Java 17'den GitHub'a tamamen taşındı. Bir versiyonun yayın süresi sıkı bir şekilde tanımlandığından, özellikler artık önceden belirlenemez. Yeni bir Java sürümü çok daha fazlasını içerir. Bu özellikler JDK (JEP) iyileştirme teklifleri olarak tanımlanır ve hepsi OpenJDK web sitesinde görüntülenebilir. Bu JEP'yi destansı sorunlara benzer şekilde hayal edebilirsiniz. Java 10'dan, sürümün ilgili sayfalarındaki sürümde bulunan JEP listesini de görebilirsiniz (Java 11 için örneğe bakınız).

Özelliklerin önizlemesi


Bazılarının bu özelliklerin uzun süre gelişmesi ve Java platformu üzerinde güçlü bir etkisi olması gerektiğinden, JEPS için önizleme ve inkübatör durumu tanıtıldı. Yeni arılar, son sürümün gelecekteki bir sürümünde Java sınıfı kütüphanesinin ayrılmaz bir parçası haline gelmeden önce Java sürümlerinde testler için zaten sonuçlanabilir. Bu arılar özel bir kuluçka paketinde bulunur ve sadece son sürümle doğru pakete taşınır. Önizleme durumu, Java platformunun yeni dil özelliklerini önceden kullanılabilir hale getirmek için kullanılabilir. Bu özellikleri bir kontrol satırı parametresi aracılığıyla etkinleştirmelisiniz:


$ javac HelloWorld.java 

$ javac --release 14 --enable-preview HelloWorld.java
$ java --enable-preview HelloWorld


Uzun vadeli destek ve kritik yamalar güncellemeleri


Her altı ayda bir yeni bir versiyonla, Java sürümlerinin ömrü süresi önemli ölçüde değişti. Artık uzun vadeli destek sürümleri (LTS) ve normal (LTS değil) arasında bir ayrım yapılmaktadır. İkincisi, bir sonraki sürümün piyasaya sürüldüğünde altı ay sürer. Java 14 Mart 2020'den Eylül 2020'ye kadar sürdü. LTS sürümleri işaretlerken, OpenJDK daha uzun ve gizli güncellemeleri daha uzun bir süre korunuyor.

Mevcut bilgiye göre, LTS Java 17 sürümü için güncellemeler olacak. Eclipse Emporttium, aşırı destek genel bakışındaki LTS sürümlerine iyi bir genel bakış sunar. LTS güncellemeleri yeni özellikler içermese de, yine de bilinen tüm güvenlik boşluklarını ayarlarlar. Bu nedenle, bu sürümlere Kritik Yama Güncellemesi (CPU) olarak da adlandırılır. LTS sürümleri olarak tanımlanmayan Java sürümleri için planlanan CPU'nun iki sürümü görünür. Örneğin, Nisan 2021'de 16.0.1 ve Temmuz 2021'de 16.0.2 sürümü Java 16 için Nisan 2021 ve 16.0.2'de CPU olarak yayınlandı. Java 17'nin görünümü ile her iki yılda bir Java'dan yeni bir LTS versiyonu olacağı tespit edilmiştir. Sonuç olarak, Java 21 Eylül 2023'te bir sonraki LTS sürümü olacak.

Bu tanımlara dayanarak, Java sürümlerinin piyasaya sürülmesinin grafiği aşağıdaki gibi Java 9'dur:








Tüm çalışmalar OpenJDK'da yapıldığından, yayın süresi bireysel Java dağılımlarından kolayca farklı olabilir. Sürüm OpenJDK'da piyasaya sürülmez, çalışma Eclipse Temurin, Oracle JDK veya Azul Zulu gibi dağıtımlar yaratmaya başlar. Her üretici, tek güç noktasından öne çıkmak için daha fazla işlevi genişletmek için OpenJDK kaynaklarını genişletmekte serbesttir. Bazıları Azul veya Bellsoft gibi, örneğin, JavaFx'i yapılarında gruplandırır.

Önceki sürümlerde, Oracle özellikle WebStart veya Mission Control gibi araçları diğer OpenJDK yapılarından öne çıkarmak için denedi. Ancak bu, toplulukta uyumluluk sorunlarına yol açtı ve neyse ki bugün artık uygulanmıyor.


(RME)
 
Üst