Java 25 / JDK 25 resmen yayımlandı

• Java 25 ve onun referans implementasyonu JDK 25 resmi olarak yayımlandı
• Bu sürüm, yeni 18 JEP (Java Enhancement Proposal) özelliği içeriyor
• x86 32 bit portunun kaldırılması, Scoped Values, Structured Concurrency, Primitive Types iyileştirmeleri gibi önemli değişiklikler uygulandı

---

Java 25 / JDK 25: Resmi yayımlanma

• Java 25’in referans implementasyonu olan JDK 25, resmi olarak üretim dağıtımı sürümü olarak yayımlandı
• 15 Ağustos 2025’te ikinci sürüm adayı olan build 36 sunuldu ve o tarihten bu yana kritik (P1) hata raporu yok.
• build 36, nihai GA (General Availability) sürümüdür ve üretim ortamlarında da kullanılabilir

• GPL lisanslı OpenJDK derlemeleri Oracle tarafından resmi olarak sunuluyor; diğer birçok tedarikçinin derleme sürümlerinin de yakında dağıtılması bekleniyor

OpenJDK resmi indirme bağlantısı

Başlıca özellikler ve iyileştirmeler

Bu sürümde 18 JEP (Java Enhancement Proposal) yer alıyor

• 470: PEM tabanlı kriptografik nesne kodlaması (preview)
• 502: Stable Values (preview)
• 503: x86 32 bit portunun kaldırılması
• 505: Structured Concurrency (5. preview)
• 506: Scoped Values
• 507: pattern, instanceof ve switch içinde Primitive Types desteği (3. preview)
• 508: Vector API (10. incubator sürümü)
• 509: JFR CPU zaman profillemesi (deneysel özellik)
• 510: Key Derivation Function API
• 511: Module Import bildirimi
• 512: Compact Source Files ve instance main method
• 513: Flexible Constructor Bodies
• 514: Ahead-of-Time komut satırı optimizasyonu
• 515: Ahead-of-Time method profillemesi
• 518: JFR iş birlikçi örnekleme
• 519: Compact Object Headers
• 520: JFR method zamanlaması ve izleme
• 521: Generational Shenandoah

Bu sürümde yukarıdaki JEP’lere ek olarak yüzlerce küçük özellik iyileştirmesi ve binlerce hata düzeltmesi de yer alıyor

Sürüme ilişkin ayrıntılı bilgiler ve JEP detayları için
OpenJDK JDK 25 proje sayfası incelenebilir

[ahwjdekf]

Geçen yıl gelen soytarı ölmemiş, yine gelmiş, hey gidi hey başlıyor... Sen niye sürekli ortaya çıkıyorsun?

[click]

Bu özellik aslında JDK24 ile gelmişti; ancak Java’da genelde yalnızca LTS sürümleri kullanıldığı için, synchronized anahtar sözcüğü kullanılırken sanal iş parçacıklarında pinning sorununu ortadan kaldıran JEP 491: Synchronize Virtual Threads without Pinning de dikkat çekmeye değer.
Sanal iş parçacıklarında gerçek dünya benchmark’larının zaman zaman daha yavaş çıktığı oluyordu ve bunun çoğu durumda nedeni pinning’di.

[GN⁺]

Hacker News görüşleri

• Daha fazla yeni programın Java veya JVM üzerinde yazılması gerektiğini düşünüyorum; geçmişte Java'nın popülerliğinin düşmesine neden olan sebeplerin çoğu artık ortadan kalktı ve bugün çok istikrarlı, olgun bir ekosistem var. 10 yıl önce yazdığım Clojure programı hâlâ sorunsuz çalışıyor ama TypeScript ile yazdığım program 6 ay içinde bakım ve güncelleme gerektiriyor.
  • Oracle meselesi büyük bir çekince. Java kullanırken Oracle'ın EULA'sını ihlal etmemeye dikkat etmek zorunda olmak rahatsız edici. OpenJDK kullanılırsa sorun olmayabilir ama insan yine de hiç endişe etmeden başka bir dil kullanmak istiyor. C# da Java'ya benzer bir ortam sunuyor ve Oracle kaygısı olmadan kullanılabiliyor. Java'yı güvenli şekilde kullanmanın yollarını öğrenmektense doğrudan başka bir dil seçmenin daha iyi olduğunu düşünüyorum. Zaten Java mutlaka gerekli de değil; alternatif çok.
  • Java, büyük ölçekli backend sistemlerde hâlâ inanılmaz derecede popüler ve yaygın biçimde kullanılıyor. Burada bu tür sistemlerle uğraşan pek kimse yokmuş gibi görünmesine şaşırıyorum. Benim deneyimimde Java neredeyse her yerde karşıma çıkıyor.
  • Kotlin ve Compose'un JVM üzerinde masaüstü uygulamalarını yeniden canlandırmasını içten içe umuyorum.
  • Java'nın benimsenme açısından hâlâ riskli tarafı ilgili kültür. Eski Java geliştiricileri ve mevcut Java programları gereksiz yere çok ayrıntılı ve uzun yazılıyor; oysa dilin kendisinde artık diğer modern diller gibi daha öz yazmayı sağlayan özellikler var. Yine de Java o kadar büyük bir varlık ki değişim ihtimali olduğunu düşünüyorum.
  • 10 yıl önce yazdığım Clojure programının hâlâ iyi çalışmasının sebebi JVM mi, yoksa Clojure'un kendine özgü yaklaşımı mı, merak ediyorum. Ben de ClojureScript projelerinde benzer bir deneyim yaşadım. Eski nbb script'leri de hemen hiç sorun çıkarmadan çalışıyor; bazen yalnızca npm bağımlılıklarını biraz elden geçirmek gerekiyor. Buna karşılık Python'da bağımlılık sorunları ve venv yönetimi yüzünden yarım gün harcadığım oldu.
• Java uzun süredir şaşırtıcı derecede sağlam bir teknik temel sağlıyor. En çekici dil olmayabilir ama her zaman istikrar gösteriyor. Java 1.4 ile yapılmış uygulama Java 21 LTS'te de sorunsuz çalışıyor ve yakında Java 25'e yükseltmeyi planlıyorum. Java harika.
  • JetBrains'in mükemmel araçları ve akıllıca kurgulanmış öğrenci programı olmasaydı Java bugün nerede olurdu merak ediyorum.
  • Biraz mesafeli olsam da, 2009'da dokunmatik Symbian telefonumda çalışan Java ile yapılmış Gmail uygulamasını hâlâ hatırlıyorum. Gerçekten sevimliydi ve işlevlerini de çok kullanmıştım.
  • Kendi deneyimime göre buna tamamen katılamıyorum. Birkaç şirkette JVM sürümü her yükseltildiğinde hep büyük sorunlar çıktı ve çok fazla yeniden çalışma ile yeniden test gerekti. Java 17~18 civarında bıraktım ama birlikte çalıştığım insanlar yeni sürümleri neredeyse hiç kullanmıyordu. 2022'de bir projede JVM 1.5'i güncellememiz gerekti, ancak kritik üçüncü taraf kütüphaneler yalnızca Java 1.7 öncesi sürümleri destekliyordu ve bu yüzden çok zorlandık. Kaynak kodunu bulup kendimiz derlemeyi denedik ama iş giderek büyüdü. Yöneticilerle de anlaşmazlık yaşadım ve sonunda Fortune 10 listesindeki en üst düzey müşterilerden biriyle çalışmayı bırakmaya karar verdim. Duyduğuma göre o sistem hâlâ güncellenemedi.
  • Eskiden yazdığım bir Swing uygulamasını yeniden denemek istiyordum; büyük değişiklikler yapmadan yeniden ayağa kaldırabilirim gibi görünüyor, o yüzden denemeyi düşünüyorum.
  • JVM ve ekosistemi Scala, Clojure gibi başka dillerle birlikte de kullanılabildiği için çeşitli ve cazip kullanım alanları sunuyor.
• Yapıcıda super çağrısından önce parametre doğrulama ve dönüştürmeye izin verilmesinin bu kadar uzun sürmesine şaşırdım. Eskiden beri sezgiye aykırı gelen bir noktaydı.
  • JDK 1.0'dan önceki dönemden beri Java kullanıyorum; bu konu eskiden beri gözüme batıyordu ama artık alıştım ve dolaylı çözümlere de iyice aşina oldum.
  • validate süreci için static fonksiyonları super parametrelerinde kullandıysanız, çağrı fiilen super öncesinde yapılmış oluyordu ve derleyici de buna itiraz etmiyordu.
• Java geliştiricisi değilim ama modül import sistemi kişisel olarak pek hoşuma gitmiyor. import * gibi sözdizimleri kod yazarken kolay olsa da okumayı çok daha zorlaştırıyor; özellikle de dile ya da kod tabanına yabancı geliştiriciler için. C# ve Nim de bu tarzda, IDE olmadan neredeyse okunmuyor. Bu yüzden Python'daki gibi kısa takma ad örneklerini (import torch.nn.functional as F) daha iyi buluyorum.
  • Büyük kod tabanlarında import ile ilgili temel sorun "bu nereden geldi?" sorusudur. Açıkça belirtilmiş import'lar kesinlikle gerekli. Özellikle derleme bozulduğunda veya bağımlılık sürümleri karıştığında bu daha da önemli oluyor. Küçük kod tabanlarında ise çok fark etmiyor. Zaten günümüz editörleri import satırlarını gizlediği için onları doğrudan pek görmüyorsunuz; koda tıklayıp ya da kısayolla doğrudan tanıma gittiğiniz için import kısmına fazla dikkat etmiyorum.
  • C# deneyiminizin çok iyi olmamasının sebebinin doğru düzgün bir Visual Studio kullanmamak olduğunu düşünüyorum. VSCode da iyi ama csproj veya sln dosyalarını asla VSCode ile açmam. Bu arada Visual Studio'yu buradan 500 dolara kalıcı lisansla satın alabiliyorsunuz ve ayrı bir abonelik gerekmiyor.
  • IDE olmadan anlaşılması zor olan dil yapılarını şikâyet etmeyi pek anlayamıyorum. Sonuçta koda IDE içinde bakıyorsunuz, bence ortada bir sorun yok. IDE kullanmayan kişi kendi rahatsızlığını kendi yaratmış oluyor. GitHub'da kod görmek de genelde referansları derinlemesine analiz etmek için yapılmıyor; dolayısıyla bu düzeydeki özlük karşılığında küçük rahatsızlıklar kabul edilebilir.
  • Bildiğim kadarıyla bu tarz, tek kaynak dosyalı program yazmayı kolaylaştırmak amacıyla tasarlanmış.
• Yeni özellikler OpenJDK 25 resmi sayfasında iyi özetlenmiş. Java 25 bir LTS sürümü.
  • 10 yıl sonra 17'den 25'e geçiş yapacağım günün bir an önce gelmesini diliyorum.
• Kişisel izlenimim şu: Java eski bir dil olmasına rağmen son 10 yılda istikrarlı şekilde gelişti, buna karşılık C++ bana giderek daha zor hale gelmiş gibi geliyor.
• Ne yazık ki structured concurrency hâlâ tamamen yayınlanmış değil. Bu özelliği gerçekten dört gözle bekliyorum. Bunun yerine Scoped Values eklenmesine sevindim; bunun bile Java'da "rails-like" tarzda kod yapıları kurarken god-class ya da god-object kullanımına abanmayı gereksiz kıldığını düşünüyorum.
  • C++ tarafında henüz implementasyonu olmadan standartlaştırılmış özelliklerin yarattığı karmaşayla kıyaslayınca, Java'nın preview üzerinden kademeli ilerleyen mevcut yaklaşımının çok daha iyi olduğunu düşünüyorum.
  • Structured concurrency'nin async/await gibi fazla şekerli bir yapıdan ziyade gerçek bir ilerleme olmasını umuyorum. Yalnızca örneklere bakınca henüz ikna olmuş değilim ama biraz daha izleyeceğim.
• Yakın zamanda JDK8'den geçiş yapmaya karar verip doğrudan JDK21'e çıktım. 25 kapıdayken 17'yi atlayıp 21'i seçtim. Bana göre 8'den 11'e geçiş en zorlu aşamaydı; çünkü yeni modül sistemi orada geldi. Ondan sonrası ise kolay. Proof-of-Concept'i jdk17 ile yapmıştım ve neredeyse aynısı jdk21'de de çalıştı; yalnızca guice için major sürüm yükseltmesi gerekti. Bu arada Java yerine başka bir JVM dili kullanmış olmam da muhtemelen yardımcı oldu.
  • Bizim ekip için 8'den 17'ye geçmek zordu. sun paketleri gibi resmî olmayan şeyleri çok kullanmıştık; javax'ten jakarta'ya geçiş de yük getirdi. O eşiği bir kez aşınca 21 veya 25'e gitmek kolay geliyor. Bundan sonra güncel sürümleri düzenli takip etmenin eskisine göre daha kolay olmasını bekliyorum.
  • Java 9 ekosistemin Python 3 anıydı, ama artık sorunsuz biçimde toparlandığını düşünüyorum.
  • Bu arada kısa süre önce 17'den 21'e geçiş yaptım ve hiç sorun yaşamadım. Küçük meseleler daha çok Gradle'ı da aynı anda yükseltirken çıktı; bu ise özünde ayrı bir konu.
• Java 25'in yeni özellikleri baeldung gönderisinde iyi özetlenmiş.
• Hukuki açıdan bugün Java kullanmanın durumu nedir merak ediyorum; hem açık kaynak hem ticari kullanım için. Oracle, Truffle gibi harika teknolojileri Java'ya bağlı tutuyor; yeni projelerde bunu kullanmak ne kadar mantıklı, bilmek istiyorum.
  • OpenJDK fiilen Oracle'dan doğrudan alınmış açık lisanslı sürüm. Oracle'dan hoşlanmıyorsanız Eclipse Foundation, Microsoft, Amazon gibi başka kurumların hazırladığı sürümleri de kullanabilirsiniz. Java'nın ömrü uzun; 8/11 gibi eski sürümlerin hâlâ kullanılıyor olmasının nedeni de bu. Bir kez yazınca gerçekten çok uzun süre çalışıyor. Özellik tarafında rakiplerine göre daha yavaş ilerlese de kritik geliştirmeler için fazlasıyla yeterli. JVM'e bağımlı kalacaksanız Kotlin'i öneririm; özellikle Java'da hâlâ nullable type olmadığı için NullPointerException sık görülüyor. Kotlin'i sevmiyorsanız C# da iyi bir seçenek. Ama Java da hâlâ gayet kullanılabilir.
  • Bugün itibarıyla Oracle dağıtımında yalnızca en güncel LTS sürümünü rahatça kullanabildiğinizi söyleyebiliriz. Daha eski sürümler OTN lisansı altında ve yalnızca kişisel/geliştirme amaçlı kullanılabiliyor; production için uygun değil. Oracle markasına özel bir gereksiniminiz yoksa OpenJDK veya diğer üreticilerin JDK'larında lisans kaygısı bulunmuyor.
  • OpenJDK tamamen açık kaynak olduğu için hiç endişelenmeye gerek yok.
  • OpenJDK gibi bir şey kullanırsanız Oracle kaynaklı sorunlardan tamamen kurtulursunuz.
  • Java'nın kendi implementasyonunu yapıp dağıtmadığınız sürece hukuki meseleler neredeyse hiç dikkate alınacak bir konu değil.