Oracle Java SE’den geçiş yapmaya hazırlanan birçok kuruluş, sürecin ne kadar süreceğini merak edecek. Ancak bu sorunun herkese uyacak tek bir cevabı yok. Geçiş için gereken süre, kuruluşa özgü en az yarım düzine değişkene bağlıdır.
Bu değişkenlerden biri firmanın geçiş hedefleridir; bazı hedeflere ulaşmak diğerlerinden daha uzun sürer. Örneğin, amaç Oracle Java’dan mümkün olan en kısa sürede tamamen geçiş yapmaksa geçiş planı, öncelikle Java 6 ve 7 gibi Java’nın eski sürümlerini çalıştıran eski uygulamalar için destek arayan bir kuruluşunkinden farklı olacaktır. daha uzun bir süre yerine aşamalı bir yaklaşımı tercih ederler.
Oracle Java SE’den geçişe hazırlanma
Geçişin ilk aşaması, kullanılan JDK sürümlerinin çeşitliliği nedeniyle genellikle Java Geliştirme Kiti (JDK) geçişinin en çok zaman alan kısmı olan Java envanterinin alınmasıdır. Genellikle yeni bir uygulama dağıtıldığında, JDK’nın o andaki en son sürümünü kullanır ve Java’nın daha yeni sürümleri yayınlansa bile onu kullanmaya devam eder. Bu oldukça mantıklı çünkü konuşlandırılan sürümle test edildi.
Uygulamanın sorunsuz çalıştığını varsayarsak JDK sürümünü güncellemeye gerek yoktur. Güncelleme yalnızca, kullanılan sürüm için güvenlik yamaları ve hata düzeltmeleri artık mevcut olmadığında ve uygulamanın performansıyla ilgili endişeler veya giderilmesi gereken bilinen bir güvenlik açığı olduğunda gereklidir.
Eksiksiz bir JDK kullanım envanteri oluşturmak için kuruluşların, kendi mülklerindeki herhangi bir Java sanal makinesi (JVM) tabanlı uygulamayı çalıştıran her makineyi incelemesi gerekir. Yazılım kullanımını izlemek için BT varlık yönetimi (ITAM) araçları kullanılırsa bu kolay olabilir. Birçok kuruluş, lisans hüküm ve koşullarına uyduklarından emin olmak için bu araçları kullanır. Bu araçlar, hangi makinelerde hangi Java sürümünün yüklü olduğunu gösteren bir raporu hızlı bir şekilde oluşturabilir. JVM’lerin sorunsuz bir şekilde envanterlenmesine yardımcı olmak için komut dosyaları Azul gibi tedarikçilerden de temin edilebilir.
Daha sonra kuruluş, envanter sırasında bulunanlara dayanarak ortaya çıkabilecek potansiyel sorunları düşünmeye başlamalıdır.
Örneğin kullanıcıların uygulamaları geliştirmek yerine satın alması oldukça yaygındır. Özel yazılımı şirket içinde geliştirmek ve sürdürmek zorunda kalmamak çok uygun maliyetli olabilir. Java kullanan bu tür uygulamaların çoğu, JDK’nın gerekli sürümünü ve hatta muhtemelen minimum sürüm güncelleme düzeyini belirtir; bu, diğer uygulamaların Windows veya Linux’un minimum sürümünü belirtme şeklinden farklı değildir.
Kullanıcı JDK’yı kaynaklamalı ve uygulamanın kullanımına sunmalıdır. Uygulama sağlayıcıları genellikle belgelerinde uygulamayı yalnızca doğru JDK ile kullanıldığında destekleyeceklerini belirtirler. Bu, uygulama geliştiricisi için mantıklıdır çünkü güncel olmayan veya uygunsuz Java çalışma zamanlarının kullanılmasından kaynaklanan sorunların ortadan kaldırılmasına yardımcı olabilir. Oracle JDK geçmişte çok yaygın olduğu için birçok uygulama sağlayıcısı yalnızca Oracle JDK’nın destek almaya hak kazanacağını belirtmişti.
Ancak Oracle JDK lisanslama ve fiyatlandırmasında yapılan son değişiklikler, kullanıcıların alternatif JDK’larda çalışırken giderek daha fazla destek talep ettiği anlamına geliyor. Artık pek çok uygulama tedarikçisi, uygulama Teknoloji Uyumluluk Kiti (TCK) sertifikalı OpenJDK yapısında çalıştığı sürece destek sağlayacak. Bu tür dağıtımların işlevsel olarak Oracle JDK ile aynı olduğuna güvenebildikleri için, uygulamalarıyla birden fazla dağıtımı test etme konusunda endişelenmelerine gerek yok.
Bazen bir uygulama, belirli OpenJDK dağıtımlarının destek için geçerli olduğunu ancak kuruluşun kullanmak istediği dağıtımın geçerli olmadığını belirtir. Bu durumda kullanıcılar gerekli dağıtımın listelerine eklenmesi için uygulama tedarikçisiyle iletişime geçmelidir. TCK testi yapıldığı sürece tedarikçinin itirazı olmasın.
Birden fazla Java uygulamasının kullanıldığı büyük organizasyonlarda uygulamaların farklı sahipleri olacaktır. Başarılı bir geçiş planlarken, ilgili tüm tarafları, yani yeni Java çalışma zamanını kullanması gereken ve/veya uygulamalarının sağlığıyla ilgilenen tüm uygulama sahiplerini dahil etmek önemlidir.
OpenJDK’ya Geçiş
OpenJDK dağıtımları güncellemeler için yerinde yama yapılmasını desteklemez; JDK’ya bir güncelleme uygulamak tamamen yeni bir JDK’nın kurulmasını gerektirir. Bu, Oracle JDK güncellemesi yerine Zulu JDK güncellemesini yüklemesi dışında, geçiş yükleme işleminin tam olarak yeni bir güncelleme dağıtma gibi ele alınabileceği anlamına gelir.
Uygulama kararlılığı sorunlarına neden olan belirli bir hata olmadığı sürece, kullanıcılar oldukça eski bir sürüm kullanıyor olsalar bile Java’nın yeni bir sürümüne geçme konusunda acil bir ihtiyaç görmezler. Ancak yönetim açısından bakıldığında, uygulamalar için en yüksek düzeyde güvenlik sağlamak amacıyla yeni bir OpenJDK dağıtımına geçiş yaparken en son güncellemeyi yüklemek her zaman iyi bir fikirdir.
Çoğu durumda güncelleme işlemi basit ve sorunsuzdur. Ancak bazen bir güncelleme, uygulamanın davranışını değiştirebilecek değişiklikler içerir.
Bir Tomcat örneği
Çok yaygın olarak kullanılan Apache Tomcat sunucu uygulaması motorunu kullanan bir örneğe bakalım. Oracle JDK 8u202’de çalışan Tomcat 8’imiz olduğunu varsayalım. Bu, Tomcat’in en son sürümü değil ancak uygulamamız için mükemmel çalıştığından yükseltilmedi. İstemciden veri alan, MySQL veritabanında sorgu yapan ve sonuç döndüren, çalışan bir sunucu uygulamamız var.
Geçişimiz için Zulu 8 güncelleme 372’yi kurup sunucuyu yeniden başlatıyoruz. Ancak uygulamayı kullanmaya çalıştığımızda iletişim bağlantısı hatası olduğunu bildiren bir hata mesajı alıyoruz. Bunun Oracle’dan Zulu’ya geçişle hiçbir ilgisi yok.
Bunun yerine, Ekim 2021’den itibaren JDK 8 güncelleme 291’de yapılan bir değişiklikten kaynaklanmaktadır. Bu güncellemede Aktarım Katmanı Güvenliği (TLS) için varsayılan ayarlar, TLSv1.0 ve TLSv1.1’i varsayılan olarak devre dışı bırakacak şekilde değiştirildi. Bu nedenle uygulamanın eskisi gibi çalışmasını sağlamak için jre/lib/security/java.security dosyasını değiştirmeli ve TLS referanslarını jdk.tls.disabled algoritmalar ayarından kaldırmalıyız.
Böyle bir şey meydana geldiğinde, sorunun farklı bir dağıtım yerine JDK’nın farklı bir güncellemesinin kullanılmasından kaynaklandığını doğrulamak önemlidir. Bu gibi durumlarda eski güncellemeleri sağlayabilecek ticari bir destek sağlayıcısına sahip olmak son derece faydalı olabilir. JDK’nın aynı güncelleme düzeyini kurmanız ve ardından uygulamayı yeniden test etmeniz yeterlidir. Örnek durumumuzda Azul destek ekibi, sorunu çözmek için gereken yapılandırma değişikliklerinin ayrıntılarını sağlayabilir.
Yeni JDK’yı yükledikten sonra, uygulamaları kullanacak şekilde değiştirmek için gerekli değişiklikleri yapmamız gerekiyor. Örneğin, JAVA_HOME ortam değişkenini ve Tomcat sunucu uygulaması motoru gibi bireysel uygulamalar için kullanılan başlatıcıları değiştirmek gerekebilir. En güvenli seçenek, taşınan tüm makinelerde bu ortam değişkenini değiştirmektir.
Kurulumdan sonra, doğru işlevsellikten emin olmak için yeni JDK’ya geçirilen tüm uygulamaları test etmeliyiz. Güncellemeler arasında değişiklik olmadığı sürece kullanıcılar muhtemelen farklı bir davranış gözlemlemeyecektir.
Doğru davranışı doğrulamak için test etme
Test süreci her uygulamaya bağlı olarak büyük ölçüde değişecektir. Dahili olarak geliştirilen uygulamalar, doğru davranışı doğrulamak için uygulamanın tüm bölümlerini tam olarak uygulayabilen kapsamlı regresyon testlerine sahip olabilir.
Üçüncü taraf uygulamalar (açık kaynak veya ticari) çalıştırılabilecek bir dizi standart teste sahip olabilir. Değilse, deneyimli bir kullanıcı uygulamayı çalıştırmalı ve mümkün olduğu kadar çok sayıda işlevsel özelliği denemelidir.
Tüm testler her kullanıcıyı memnun edecek şekilde geçtikten sonra geçiş işlemi tamamlanır. Kuruluş artık Java varlıklarını en yüksek düzeyde güvenlik ve istikrarla koruyacak, genellikle eskisinden daha güçlü bir konumda olacak. Buna ek olarak, Java çalışma zamanının nerede kullanıldığına dair net bir resme sahip olacak ve makineleri en son Java güncellemesine yükseltme konusunda daha fazla deneyime sahip olacak.
Bu makale şu kaynaktan bir alıntıya dayanmaktadır: Aptallar için OpenJDK geçişi, Azul özel sürümüJava şampiyonu Simon Ritter tarafından.