Microsoft Build of OpenJDK: Java 11 ve 17 için 2027 Sınırı
Azure üzerinde Java çalıştıran ekipler için takvim artık belli. Microsoft Build of OpenJDK destek yol haritası, Java 11 ve 17 için en erken destek bitiş tarihi olarak Eylül 2027’yi gösteriyor. Azure App Service ve Azure Functions tarafında da Java 8, 11 ve 17 desteği aynı dönemde bitiyor. Bu yazıda hangi tarihin hangi senaryoyu bağladığını, Java 21 ya da 25’e geçişi tek bir servisten başlatarak nasıl planlayabileceğinizi ve GitHub Copilot modernizasyon araçlarının bu süreçte nerede işe yaradığını özetliyorum.
Nereden buraya gelindi
Microsoft, Nisan 2021’de Microsoft Build of OpenJDK’yı duyurduğunda yola Windows, Linux ve macOS için Java 11 derlemelerinin önizlemesiyle çıkmıştı. Aynı çalışmanın üzerine bugün birden fazla kuşak eklendi: 11, 17, 21 ve 25.
Java 8 tarafında ise Microsoft kendi OpenJDK 8 derlemesini üretmedi, Eclipse Foundation’ın Eclipse Adoptium projesinin Eclipse Temurin derlemelerini kullanarak Azure üzerinde destek verdi. Bu iş birliği başlangıca kadar uzanıyor; ilk Java 11 derlemeleri de Adoptium’un derleme betiklerinden ve kalite güvence paketinden yararlanmıştı.
2027 kilometre taşları: dağıtım mı, servis mi?
Burada en sık karıştırılan şey, JDK dağıtımının destek takvimiyle Azure servislerinin destek takviminin aynı şey sanılması. İkisini ayrı ayrı kontrol etmek gerekiyor.
Microsoft Build of OpenJDK (nereye dağıtırsanız dağıtın)
- Java 11 ve 17 için en erken destek bitişi: Eylül 2027
- Java 21 için: Eylül 2028
- Java 25 için: Eylül 2030
Bunlar başlangıç hedefleri, Microsoft tarihleri uzatabilir. Yine de dağıtım genelinde geçerli bir eşik sayılır. Microsoft derlemelerini bir sanal makinede, konteyner içinde, Kubernetes üzerinde, Azure platform servislerinde ya da Azure dışında kullanıyorsanız bu tarih yükseltme planınıza giriyor. Müşteri tarafından yönetilen JDK’larda (VM, konteyner, Kubernetes) JDK güncellemelerinin ve dağıtımının sorumluluğu sizin ekibinizde.
Yönetilen App Service ve Functions çalışma zamanları
Azure App Service ve Azure Functions için Java 8, 11 ve 17 desteği 1 Eylül 2027’de sona eriyor. Mevcut uygulamalar çalışmaya devam ediyor, ama etkilenen Java sürümleri artık güvenlik güncellemesi, iyileştirme veya ilgili müşteri desteği almıyor. Bu modelde JDK bakımını Microsoft üstleniyor, desteklenen ana sürümü seçmek ve test etmek size kalıyor. Servis takvimleri dağıtım yol haritasından farklılaşabilir.
Ticari destek koşulları
Microsoft Build of OpenJDK için ticari destek; aktif bir Azure Destek Planı, Azure, Azure Stack servisleri veya Azure Arc kümelerinde uygun bir dağıtım ve güncel sürüm kullanımı istiyor. Java 8 ilgili Azure senaryolarında Eclipse Temurin üzerinden ilerlediği için onun dağıtım ve servis politikalarını da ayrıca kontrol edin. Diğer sağlayıcılar kendi destek şartlarını belirler.
İlk servisi değerlendirin: Modernize CLI
Uygulama çalışır durumda kalırken Java 21 veya 25’e nasıl çıkılır? Pratikte iş buraya dayanıyor. GitHub Copilot modernizasyonunun sunduğu Modernize CLI kodu değerlendirebiliyor, yükseltmeyi planlamaya yardımcı oluyor, değişiklikleri sizin incelemeniz için uygulayabiliyor.
Aracı kurmak ve kimlik doğrulaması yapmak için Modernize CLI hızlı başlangıç belgesini izleyin; bir GitHub Copilot aboneliği ve GitHub CLI gerekiyor. Uygulamanın deposu içinden:
modernizeAssess adımını seçin, uygulamayı belirleyin, Java upgrade değerlendirme alanını dahil edin ve hedef çalışma zamanını tanımlayın. Değerlendirme kodu, bağımlılıkları ve yapılandırmayı inceliyor, raporları .github/modernize/assessment/ altına kaydediyor.
Bu aşamada sorular somut olmalı: Kullandığınız Spring Boot sürümü Java 21’i destekliyor mu? Maven eklentileri ve test araçları bu JDK üzerinde çalışabiliyor mu? Değişmesi gereken bağımlılık veya API kullanımları var mı? Bulguları üretim bilginizle birlikte okuyun, çünkü dağıtım anında enjekte edilen bir izleme ajanı ya da depo dışında yönetilen bir veritabanı sürücüsü de yükseltme planının parçası.
Ajana sınır çizin ve planı siz düzenleyin
Değerlendirme akışından Create modernization plan seçeneğine geçip raporu bağlam olarak kullanın. “Her şeyi modernize et” demek yerine inceleyebileceğiniz ölçekte bir değişiklik tarif edin: servisi Java 21’e yükseltmek, değerlendirme bulgularından gerekli bağımlılık ve derleme aracı değişikliklerini çıkarmak, HTTP API’sini ve dağıtım hedefini korumak, derleme ile birim ve entegrasyon testi adımlarını dahil etmek, zorunlu uyumluluk değişikliklerini isteğe bağlı refactoring’den ayırmak, framework göçlerini inceleme için işaretlemek.
Plan Spring Boot 2’den 3’e geçiş öneriyorsa işin içinde bir Jakarta ad alanı göçü de var demektir. Bu framework değişikliğinin seçtiğiniz hedef için zorunlu olup olmadığını kontrol edin, sıralamasına da yürütmeden önce karar verin.
Üretilen plan .github/modernize/{plan-name}/plan.md altında duruyor. Bu dosyayı düzenleyin, ekibinizin güvendiği entegrasyon testlerini, sabit kalması gereken API davranışını ve kaynak koddan anlaşılmayan dağıtım kontrollerini ekleyin. Planın amacı, bu kararları büyük bir diff’e dönüşmeden önce vermek.
Planı pull request’e çevirin
Planı inceledikten sonra Execute adımını seçebilirsiniz. Ajan kod dönüşümlerini uygulayabiliyor, bağımlılıkları yükseltebiliyor, derlemeleri doğrulayabiliyor. Değişiklikleri ve commit geçmişini, başka bir katkıya nasıl davranıyorsanız öyle gözden geçirin.
Kapsamı zaten biliyorsanız CLI’nin planlama ve yürütmeyi birleştiren bir akışı da var:
modernize upgrade "Java 21"Yine de ilk yükseltmede değerlendirme ve planlama adımlarını ayrı yürütmek, kararları yürütmeden önce görebilmeniz açısından daha güvenli. Her iki yolu da CLI referansı kapsıyor.
Pull request’i bir sonraki geliştiricinin kolayca anlayacağı şekilde yazın: başlangıç ve hedef Java sürümleri, her framework ve bağımlılık değişikliğinin gerekçesi, derleme ve test sonuçları. İlgisiz refactoring’i dışarıda bırakın. İnceleyen kişi üç soruyu yanıtlayabilmeli: Ne değişmek zorundaydı? Ne aynı kaldı? Birleştirmeyi hangi kanıt destekliyor?
CI ve üretimi eski JDK’da bırakmayın
GitHub Actions hala Java 17 ile test ediyorsa ya da üretim eski bir konteyner imajını başlatıyorsa yerelde başarılı bir Java 21 derlemesinin hiçbir anlamı kalmaz.
Maven derleyici ve toolchain ayarlarını, GitHub Actions’ta sağlanan JDK ile birlikte gözden geçirin. actions/setup-java gibi bir action derleme JDK’sını yapılandırabiliyor; derleme eklentilerinin ve action uyumluluğunun da kontrol edilmesi gerekiyor. Ardından Azure çalışma zamanı yapılandırmasını seçtiğiniz hedefle hizalayın. Müşteri tarafından yönetilen konteynerlerde yeni JDK’yı içeren imajı yeniden derleyip dağıtın.
Birim ve entegrasyon testlerini çalıştırın, sonra gerçekçi yapılandırmayla staging ortamına dağıtın. HTTP uç noktalarını ve veritabanı çağrılarını deneyin, izleme ajanının başladığını doğrulayın, hata, gecikme ve bellek değerlerini mevcut temel ölçümle karşılaştırın. Derlemenin geçmesi tek bir kontrol; servisin gerçekten çalıştığını bunlar söylüyor.
Servisinizin desteklediği kademeli dağıtım mekanizmasını kullanın, hem uygulama artefaktı hem de çalışma zamanı yapılandırması için elinizde bir geri alma yolu bulunsun. Bu temel kurulduktan sonra yeni Java yeteneklerini ayrıca değerlendirebilirsiniz. Sanal iş parçacıkları (virtual threads) mesela uygun iş yükleri için incelemeye değer, ama uyumluluk yükseltmesinin parçası olmak zorunda değil. Küçük değişiklikleri incelemek de sorun gidermek de daha kolay.
Sonraki yükseltmeyi kolaylaştırmak
İlk servisten elinize yalnızca güncellenmiş bir çalışma zamanı geçmiyor; incelenmiş bir plan, ortak engellerin listesi ve yeniden kullanılabilir bir kontrol seti de kalıyor. Modernize CLI birden fazla depoyu ve yeniden kullanılabilir modernizasyon becerilerini (skills) desteklediği için her uygulamayı sıfırdan ele almanız gerekmiyor.
Bruno Borges’in Microsoft Reactor’da yaptığı “The Agentic SDLC: Making Application Modernization Continuous” sunumunun ana fikri de bu: modernizasyonu, destek takvimi daraldığında başlatılan tek seferlik bir proje olmaktan çıkarıp yazılım bakımının sürekli bir parçası haline getirmek. 2027 kilometre taşları başlamak için iyi bir gerekçe; tek bir servis, açıkça tanımlanmış bir hedef ve ekibinizin güvenle inceleyebileceği bir pull request ile ilerleyebilirsiniz.
Kaynaklar ve İleri Okuma
- Plan Your Java Upgrade Ahead of Microsoft’s 2027 Support Milestones (Bruno Borges, Microsoft for Java Developers)
- Microsoft Build of OpenJDK destek yol haritası
- Microsoft Build of OpenJDK önizleme duyurusu (2021)
- Azure güncellemesi: App Service ve Functions Java destek bildirimi
- Azure App Service dil desteği politikası
- Azure Functions Java destek tablosu
- GitHub Copilot app modernization belgeleri
- Modernize CLI hızlı başlangıç
- Modernize CLI komut referansı
- Eclipse Adoptium projesi
- Microsoft for Java Developers blogu
- Java OpenJDK Nisan 2026 Güncellemesi: Bellek, Güvenlik ve Sürprizler
- GitHub Copilot Upgrade Canvas:.NET Modernizasyonu Yeni Boyutta
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
Yorum gönder