[TR] Ubuntu 24.04’te Varsayılan Java Sürümü Nasıl Değiştirilir?

Ubuntu üzerinde Java tabanlı uygulamalarla çalışıyorsanız sisteminizde zamanla birden fazla Java sürümünün birikmesi oldukça normaldir.

Özellikle farklı projeler, uygulama sunucuları, geliştirme araçları veya eski-yeni nesil yazılımlar aynı makinede çalışıyorsa, her birinin ihtiyaç duyduğu Java sürümü farklı olabilir.

Tam da bu noktada sistemin varsayılan Java sürümünü değiştirme ihtiyacı ortaya çıkar.

Örneğin bir uygulama Java 21 ile sorunsuz çalışırken başka bir uygulama yalnızca Java 17 üzerinde stabil olabilir. Benzer şekilde bazı eski yazılımlar Java 8 bağımlılığıyla gelir. Ubuntu’da bu tür sürüm geçişlerini yönetmek mümkündür ve doğru araç kullanıldığında işlem oldukça düzenli şekilde yapılabilir.

Bu makalede Ubuntu 24.04 üzerinde varsayılan Java sürümünün nasıl değiştirileceğini, bu işlemin neden önemli olduğunu, hangi komutların ne işe yaradığını ve işlem sonrasında nelere dikkat edilmesi gerektiğini detaylı şekilde ele alacağız.

Neden Varsayılan Java Sürümünü Değiştirmek Gerekir?

Bir Linux sistemde aynı anda birden fazla Java sürümünün kurulu olması çok yaygın bir durumdur. Bunun temel nedeni her uygulamanın aynı Java sürümünü istememesidir.

Karşılaşılabilecek tipik senaryolar şunlardır:

• Eski bir kurumsal uygulama yalnızca Java 8 ile çalışabilir
• Yeni nesil bir backend servisi Java 17 veya Java 21 gerektirebilir
• Geliştirme ortamında farklı projeler için farklı JDK sürümleri kullanılabilir
• Maven, Gradle, Jenkins veya IntelliJ gibi araçlar belirli sürüm beklentilerine sahip olabilir
• Bazı uygulama sunucuları ve middleware çözümleri belirli Java sürümleriyle daha uyumlu olabilir

Bu nedenle, sadece Java’nın kurulu olması yeterli değildir. Aynı zamanda sistemin hangi Java sürümünü varsayılan olarak kullanacağını bilmek ve gerektiğinde bunu değiştirebilmek gerekir.

Ubuntu’da Varsayılan Java Nedir?

Ubuntu’da terminalde java komutunu çalıştırdığınızda, sistem doğrudan gerçek Java binary dosyasını çağırmaz. Bunun yerine çoğu zaman /usr/bin/java üzerinden bir sembolik bağlantı kullanılır. Bu bağlantı, sistemde kayıtlı alternatif Java kurulumlarından birine yönlendirilir.

İşte burada update-alternatives mekanizması devreye girer. Ubuntu ve Debian tabanlı sistemlerde bu yapı, aynı görevi yapan birden fazla yazılım sürümü arasından hangisinin varsayılan olarak kullanılacağını belirlemek için kullanılır.

Yani sisteminizde Java 8, Java 17 ve Java 21 kurulu olabilir; fakat java komutu bunlardan yalnızca birini çağırır. Hangi sürümün çağrılacağını ise alternatif yapılandırması belirler.

İşleme Başlamadan Önce Bilinmesi Gerekenler

Varsayılan Java sürümünü değiştirme işlemi sistem genelinde etkili olabileceği için yönetici yetkisi gerektirir. Bu nedenle aşağıdaki komutları çalıştırabilmek için genellikle sudo yetkisine sahip olmanız gerekir.

Eğer bir sunucu ortamında çalışıyorsanız, yapılan değişiklik yalnızca sizin oturumunuzu değil, sistem genelinde Java kullanan diğer servisleri de etkileyebilir. Özellikle production ortamlarda bu işlemi yapmadan önce hangi servislerin mevcut Java sürümünü kullandığını kontrol etmek faydalı olacaktır.

Mevcut Varsayılan Java Sürümünü Kontrol Etmek

İlk adım olarak, sistemde şu anda hangi Java sürümünün varsayılan olarak kullanıldığını görmek gerekir. Bunun için terminalde aşağıdaki komutu çalıştırabilirsiniz:

java --version

Bu komut, aktif Java sürümünü ekrana yazdırır. Örneğin şöyle bir çıktı görebilirsiniz:

openjdk 21.0.2 2024-01-16

Bu çıktı bize sistemin şu anda varsayılan olarak Java 21 kullandığını gösterir.

Bazı ortamlarda aşağıdaki komut da kullanılabilir:

java -version

Her iki komut da benzer amaçla kullanılır; ancak --version daha modern ve okunabilir bir çıktı sunar.

Sistemde Kurulu Java Sürümlerini Listeleme

Eğer sisteminizde birden fazla Java sürümü kuruluysa, bunları yönetmek için update-alternatives aracı kullanılır. Varsayılan sürümü değiştirmek için şu komutu çalıştırın:

sudo update-alternatives --config java

Bu komut çalıştırıldığında Ubuntu, sistemde tanımlı Java alternatiflerini listeler. Ekranda aşağıdakine benzer bir çıktı görürsünüz.

There are 3 choices for the alternative java (providing /usr/bin/java).

  Selection    Path                                         Priority   Status
------------------------------------------------------------
* 0            /usr/lib/jvm/java-21-openjdk-amd64/bin/java   2111      auto mode
  1            /usr/lib/jvm/java-17-openjdk-amd64/bin/java   1711      manual mode
  2            /usr/lib/jvm/java-21-openjdk-amd64/bin/java   2111      manual mode
  3            /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java 1081     manual mode

Press <enter> to keep the current choice[*], or type selection number:

Bu çıktı ilk bakışta basit görünse de, aslında önemli bilgiler içerir.

Ekrandaki Seçenekler Ne Anlama Geliyor?

Yukarıdaki listede yer alan alanları doğru okumak önemlidir:

Selection

Bu sütun, seçebileceğiniz Java sürümlerinin numarasını gösterir. Varsayılan sürümü değiştirmek istediğinizde buradaki numarayı girersiniz.

Path

İlgili Java çalıştırılabilir dosyasının sistemde bulunduğu tam dizini gösterir. Buradan hangi Java kurulumunun hangi klasörde yer aldığını anlayabilirsiniz.

Priority

Bu alan, otomatik modda sistemin hangi Java sürümünü tercih edeceğini belirleyen öncelik değeridir. Sayı ne kadar yüksekse, sistem otomatik seçimde o sürümü öne alır.

Status

Burada iki farklı durum karşınıza çıkar:

• auto mode: Sistem, öncelik değerine göre uygun sürümü otomatik seçer
• manual mode: Kullanıcı sürümü elle seçmiştir ve sistem artık o tercihi kullanır

Yıldız işareti (*)

Satırın başındaki *, o anda aktif olan varsayılan Java sürümünü gösterir.

Varsayılan Java Sürümünü Değiştirme

Diyelim ki sisteminizde şu anda Java 21 aktif, ancak siz Java 17 kullanmak istiyorsunuz. Bu durumda listede Java 17’nin karşısında görünen seçim numarasını girmeniz gerekir.

Örneğin:

Press <enter> to keep the current choice[*], or type selection number: 1

Burada 1 yazıp Enter tuşuna bastığınızda sistem varsayılan Java sürümünü Java 17 olarak değiştirir.

Bu işlem tamamlandığında Ubuntu artık /usr/bin/java komutunu Java 17 yoluna yönlendirecektir.

Değişikliğin Uygulandığını Doğrulama

Seçim yaptıktan sonra işlem gerçekten başarıyla gerçekleşti mi, bunu kontrol etmeniz gerekir. Bunun için tekrar şu komutu çalıştırın:

java --version

Eğer değişiklik sorunsuz şekilde tamamlandıysa aşağıdakine benzer bir çıktı alırsınız:

openjdk 17.0.10 2024-01-16

Bu sonuç, sistemin artık varsayılan olarak Java 17 kullandığını net şekilde gösterir.

Sadece java Değil, javac da Kontrol Edilmeli

Çok önemli ama sık atlanan bir detay vardır: java komutu çalışma zamanı ortamını temsil ederken, javac komutu Java derleyicisidir. Özellikle yazılım geliştirme yapıyorsanız sadece java sürümünü değiştirmek yeterli olmayabilir.

Eğer java Java 17’ye, javac ise Java 21’e işaret ediyorsa derleme ve çalıştırma süreçlerinde sürüm uyuşmazlıkları yaşayabilirsiniz. Bu nedenle derleyici sürümünü de kontrol etmek gerekir.

Önce aktif derleyici sürümünü kontrol edin:

javac --version

Gerekirse aşağıdaki komutla javac alternatifini de değiştirin:

sudo update-alternatives --config javac

Burada da tıpkı java komutunda olduğu gibi istediğiniz sürüm numarasını seçebilirsiniz.

En sağlıklı yaklaşım, java ve javac için aynı ana sürümü kullanmaktır.

Aktif Java Yolunu Doğrudan Görüntülemek

Bazen sürüm çıktısı yeterli olmaz ve sistemin hangi fiziksel dosyaya yönlendiğini doğrudan görmek istersiniz. Bunun için aşağıdaki komut kullanılabilir.

readlink -f /usr/bin/java

Bu komut, sembolik bağlantının gerçek hedefini gösterir. Örneğin şöyle bir sonuç dönebilir:

/usr/lib/jvm/java-17-openjdk-amd64/bin/java

Bu da aktif Java yolunun gerçekten Java 17 olduğunu doğrular.

Benzer kontrolü javac için de yapabilirsiniz.

readlink -f /usr/bin/javac

JAVA_HOME Değişkeni Neden Önemli?

Bazı uygulamalar ve araçlar sistem varsayılanından ziyade JAVA_HOME ortam değişkenine bakar. Bu nedenle siz update-alternatives ile varsayılan Java’yı değiştirmiş olsanız bile, ilgili uygulama hâlâ eski Java yolunu kullanıyor olabilir.

Bu durum özellikle aşağıdaki araçlarda sık görülür:

• Maven
• Gradle
• Tomcat
• Jenkins
• IntelliJ IDEA
• Spring tabanlı uygulamalar
• Bazı shell script’ler ve servis dosyaları

Mevcut JAVA_HOME değerini görmek için:

echo $JAVA_HOME

Eğer burada eski bir Java dizini tanımlıysa, uygulamanın beklenmedik şekilde farklı sürüm kullanmasına neden olabilir.

Geçici olarak JAVA_HOME tanımlamak için örnek kullanım:

export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64
export PATH=$JAVA_HOME/bin:$PATH

Bu değişiklik yalnızca mevcut oturum için geçerli olur. Kalıcı hale getirmek isterseniz .bashrc, .profile veya sistem servis yapılandırmalarını düzenlemeniz gerekir.

Auto Mode ve Manual Mode Arasındaki Fark

update-alternatives çıktısında gördüğünüz auto mode ve manual mode, sürüm yönetimi açısından önemlidir.

Auto Mode

Bu modda sistem, öncelik değeri en yüksek olan Java sürümünü otomatik olarak seçer. Yeni bir Java sürümü kurulduğunda, eğer önceliği daha yüksekse sistem varsayılanı otomatik olarak değişebilir.

Bu davranış bazı kullanıcılar için pratik olsa da, sunucu ve uygulama ortamlarında sürümün beklenmedik şekilde değişmesine neden olabilir.

Manual Mode

Bu modda seçim kullanıcı tarafından açıkça yapılır. Sistem, yeni bir Java sürümü kurulsa bile seçilen sürümü korur. Özellikle kararlı çalışma gerektiren sunucularda çoğu zaman daha güvenli yöntem budur.

Bu İşlem Sonrasında Hangi Problemler Çözülebilir?

Varsayılan Java sürümünü doğru şekilde ayarlamak şu tür sorunların önüne geçebilir:

• Uygulamanın açılmaması
• “Unsupported class version” hataları
• Maven veya Gradle derleme hataları
• Jenkins job’larının başarısız olması
• Uygulama sunucusunun yanlış Java ile başlaması
• Geliştirme ortamı ile production ortamı arasında sürüm uyuşmazlığı yaşanması

Özellikle Java projelerinde alınan birçok hata, doğrudan koddan değil yanlış aktif Java sürümünden kaynaklanır. Bu yüzden sürüm kontrolü, temel ama kritik bir sistem yönetimi adımıdır.

Uygulama Sunucularında Ek Kontroller Gerekebilir

Eğer Ubuntu üzerinde yalnızca terminal kullanımı değil de bir servis çalıştırıyorsanız, iş biraz daha dikkat gerektirir. Çünkü bazı servisler başlangıçta belirli bir Java yolunu sabit olarak kullanır.

Örneğin:

• systemd servis dosyaları içinde özel Java yolu tanımlı olabilir
• Tomcat veya WildFly gibi sunucular kendi ortam dosyalarından Java okuyabilir
• Docker container içinde çalışan uygulama, host sistemden bağımsız Java kullanıyor olabilir

Yani sistemde varsayılan Java’yı değiştirmiş olmanız, her zaman tüm uygulamaların otomatik olarak yeni sürüme geçtiği anlamına gelmez. Özellikle servis bazlı uygulamalarda servis tanımlarının ve environment dosyalarının da kontrol edilmesi gerekir.

Örnek Senaryo

Diyelim ki Ubuntu 24.04 sisteminizde şu sürümler kurulu:

• Java 8
• Java 17
• Java 21

Sistem şu anda Java 21 kullanıyor. Ancak çalıştırmak istediğiniz uygulama yalnızca Java 17 ile uyumlu. Böyle bir durumda yapmanız gereken işlem şudur:

Önce aktif sürümü kontrol edersiniz:

java --version

Sonra alternatif listesini açarsınız:

sudo update-alternatives --config java

Listeden Java 17’ye karşılık gelen numarayı seçersiniz. Ardından tekrar doğrulama yaparsınız:

java --version

Gerekirse javac için de aynı işlemi tekrar edersiniz. Son olarak JAVA_HOME değişkenini ve servis yapılandırmalarını kontrol ederek ortamı tamamen tutarlı hale getirirsiniz.

Ubuntu 24.04 üzerinde varsayılan Java sürümünü değiştirmek, özellikle çoklu Java kurulumlarının bulunduğu sistemlerde bilinmesi gereken temel bir yönetim işlemidir. İşlem teknik olarak zor değildir; ancak neyin değiştiğini ve bu değişikliğin sistemde hangi bileşenleri etkileyebileceğini bilmek önemlidir.

Özetle süreç şu mantıkla ilerler:

Önce aktif Java sürümü kontrol edilir, ardından update-alternatives aracıyla istenen sürüm seçilir, sonrasında bu değişiklik doğrulanır. Geliştirme ortamlarında javac ve JAVA_HOME kontrolleri de yapılarak sürüm tutarlılığı sağlanır.

Doğru Java sürümünü kullanmak; uygulama uyumluluğu, derleme süreçleri, servis kararlılığı ve sistem yönetimi açısından ciddi fark yaratır. Özellikle birden fazla projenin aynı sistemde çalıştığı ortamlarda bu konu küçük bir detay değil, doğrudan operasyonel bir gerekliliktir.