Büyük Yakınsama: JDK 28’de Project Valhalla, Leyden AOT, Babylon GPU Hızlandırma ve Yeni Nesil JVM Mimarisi

Yazılım mühendisliği tarihinde bazı sürümler yalnızca artımlı (incremental) iyileştirmeler sunar; bazıları ise üzerinde çalıştığı sanal makinenin fizik kurallarını baştan yazar. OpenJDK ekosisteminde yıllardır birbirinden bağımsız kulvarlarda geliştirilen devrimsel projeler —Project Valhalla, Project Leyden, Project Babylon, Project Panama ve Project Loom— nihayet JDK 28 çatısı altında tarihi bir kesişim noktasına ulaştı.

OpenJDK ana dalına (mainline) 1.816 dosyada 197.000'den fazla satır kod ekleyen devasa PR'ın birleştirilmesiyle birlikte, Java topluluğunun 12 yıldır beklediği Project Valhalla artık soyut bir araştırma projesi olmaktan çıkıp somut bir derleyici ve JVM gerçeğine dönüştü. Ancak JDK 28'i gerçek anlamda bir "Büyük Yakınsama" (Grand Convergence) haline getiren şey yalnızca Valhalla değil; aynı sürüm penceresinde Project Leyden'in AOT (Ahead-of-Time) makine kodu derlemesini (JEP 544) getirmesi, ZGC'nin otonom bellek yönetimine (JEP 545 & 546) kavuşması, Project Loom'un Yapılandırılmış Eşzamanlılığı (JEP 543) tamamlaması ve Project Babylon'un saf Java kodunu GPU çekirdeklerine derleyen mimarisini olgunlaştırmasıdır.

Bu derinlemesine teknik incelemede, JDK 28 ile gelen yeni nesil JVM mimarisinin kaputunun altına iniyor; bellek yerleşiminden (memory layout) AOT kod önbelleklemesine, sembolik kod yansımasından (code reflection) otonom çöp toplayıcılara kadar tüm alt sistemleri mimari düzeyde analiz ediyoruz.

1. JVM'in 30 Yıllık Mirası ve Modern Donanım Asimetrisi

Java'nın doğduğu 1990'ların ortasında, bir CPU komutunun yürütülmesi ile ana bellekten (RAM) veri getirilmesi arasındaki gecikme farkı yalnızca birkaç saat döngüsüydü (clock cycle). Bugün ise modern bir sunucu işlemcisinde L1 önbellek erişimi ~1 nanosaniye sürerken, ana belleğe gitmek (DRAM access) 80 ila 100 nanosaniyeye mal oluyor; bu da işlemcinin yüzlerce döngü boyunca hiçbir iş yapmadan beklemesi (CPU stall) anlamına geliyor.

Geleneksel JVM mimarisi, bu donanım evriminin karşısında üç temel darboğazla karşı karşıya kaldı:

1. Kimlik Vergisi ve İşaretçi Takibi (Pointer Chasing): Java'da int, double gibi 8 ilkel (primitive) tip dışındaki her şey bir referans nesnesidir (Object). Küçük bir LocalDate, Optional veya 3 boyutlu bir koordinat (Point3D) tanımladığınızda, JVM bu nesneye benzersiz bir kimlik (identity) atar. Her nesne yığında (heap) ayrı bir başlık (JDK 27'deki Compact Object Headers / JEP 534 ile 64-bit'e inmiş olsa bile) ve ona işaret eden 32/64-bit'lik bir referans taşır. Bir Point3D[] dizisi aslında bitişik verilerden değil, belleğin rastgele bölgelerine dağılmış nesnelere giden işaretçilerden oluşur. CPU önbellek satırı (cache line) bu yapıda sürekli ıskalama (cache miss) yaşar.
2. JIT Isınma (Warmup) Paradoksu: HotSpot JVM'in C1 ve C2 derleyicileri, çalışma zamanında kodun profilini çıkararak muazzam bir zirve performansı (peak performance) üretir. Ancak mikroservislerin ve sunucusuz (serverless) iş yüklerinin saniyeler içinde ölçeklendiği bulut-yerel (cloud-native) dünyada, sınıfların yüklenmesi, doğrulanması, yorumlayıcıda (interpreter) çalışması ve C2 tarafından derlenmesi sırasında harcanan CPU ve zaman maliyeti kabul edilemez bir soğuk başlatma (cold start) gecikmesi yaratır.
3. Bytecode Duvarı ve Silikon Körlüğü: Geleneksel Java derleyicisi (javac), yüksek seviyeli kodu yığın tabanlı (stack-based) JVM bytecode'una indirger. Bu işlem sırasında kodun yüksek seviyeli matematiksel ve yapısal niyeti kaybolur. Sonuç olarak JVM, matris çarpımı veya vektör indirgeme gibi paralel işlemleri GPU veya NPU gibi heterojen hızlandırıcılara devredemez; geliştiricileri JNI (Java Native Interface) veya Python köprülerine mahkum eder.

"Mimari Not: JDK 28, bu üç tarihsel darboğazı birbirinden kopuk yamalarla değil; veri katmanında Valhalla, çalışma zamanı katmanında Leyden ve hesaplama katmanında Babylon/Panama işbirliğiyle bütünsel olarak çözen ilk sürümdür."

2. Project Valhalla: JEP 401 (Value Objects) ve JEP 539 (Strict Field Initialization)

On yılı aşkın bir geliştirme sürecinin ardından JDK 28'e entegre edilen JEP 401 (Value Classes and Objects - Preview), Java'nın nesne modelini kökten değiştiriyor. Valhalla'nın felsefesi tek bir cümlede özetlenir: "Bir sınıf gibi kodlanır, bir int gibi çalışır" (Codes like a class, works like an int).

Nesne Kimliğinin (Object Identity) Ortadan Kaldırılması

Bir nesnenin kimliği olması; onun bellekte benzersiz bir adresi olması, alanlarının değiştirilebilir (mutable) olabilmesi veya üzerinde kilitlenme (synchronized) yapılabilmesi demektir. Oysa finansal bir tutarı (CurrencyAmount), bir karmaşık sayıyı (Complex) veya bir yapay zeka gömme (embedding) vektör elemanını (Float16) temsil ederken kimliğe ihtiyacımız yoktur. 5 sayısı başka bir 5 sayısından adres olarak farklı olmak zorunda değildir; değeri onun kimliğidir.

JEP 401 ile bir sınıfı value class veya value record olarak işaretlediğinizde, JVM'e şu mimari sözü verirsiniz: "Bu nesnenin kimliği yoktur, tüm alanları örtük olarak final'dır (değiştirilemez) ve kimliğe duyarlı hiçbir işleme (synchronized, System.identityHashCode, WeakReference) tabi tutulamaz".

Skalarlaştırma (Scalarization) ve Yığın Düzleştirme (Heap Flattening)

Kimlik zorunluluğu ortadan kalktığında, HotSpot JVM iki devasa optimizasyonu devreye sokar:

1. Çağrı Yığınında Skalarlaştırma (Scalarization on Stack / Registers): Bir value nesnesi metot parametresi olarak geçirildiğinde veya yerel değişken olarak kullanıldığında, JVM yığında (heap) hiçbir bellek tahsisi (allocation) yapmaz. Nesneyi bileşenlerine (alanlarına) ayırır ve bu alanları doğrudan CPU yazmaçları (registers) üzerinden taşır. Çöp toplayıcı (GC) bu nesnenin varlığından bile haberdar olmaz.
2. Yığın ve Dizi Düzleştirme (Reference & Array Flattening): Bir sınıfın alanı veya bir dizinin elemanı bir value class olduğunda, JVM işaretçi (pointer) saklamak yerine nesnenin ham bitlerini doğrudan kapsayıcı nesnenin veya dizinin belleğine gömer (inlining).

JEP 539: Strict Field Initialization in the JVM

Valhalla'nın güvenli bir şekilde bellek düzleştirmesi yapabilmesi için JVM seviyesinde kritik bir altyapı değişikliği gerekiyordu: JEP 539 (Strict Field Initialization in the JVM - Preview).

Geleneksel Java'da bir yapıcı metot (constructor) çalışırken, üst sınıfın yapıcısı (super()) çağrılmadan önce this referansı dışarı sızdırılabilir veya nesne henüz tam başlatılmamışken gözlemlenebilir. Kimliği olmayan ve bellekte kopyalanarak taşınan bir value object için yarı-başlatılmış (partially initialized) bir durumun görülmesi, bellek güvenliğini (memory safety) ve değişmezlik (immutability) garantisini tamamen bozar.

JEP 539 (ve onun dil seviyesindeki karşılığı olan Esnek Yapıcı Gövdeleri), JVM sınıf dosyası doğrulayıcısına (verifier) Strict Fields (ACC_STRICT_INIT) kavramını getirir. Bir value class içindeki tüm örnek alanları (instance fields), super() çağrısı gerçekleşmeden, yani nesne varlık kazanıp dış dünyaya açılmadan önce kesin olarak başlatılmak zorundadır.

// JDK 28 — JEP 401 (Value Objects) & JEP 539 (Strict Initialization)
// Derleme: javac --enable-preview --release 28 VectorKernel.java

public value class Float16 {
    private final short bits; // Örtük olarak final ve strict-init

    public Float16(float value) {
        // JEP 539: super() çağrısından önce alan başlatımı gerçekleşir (Erken Başlatım Fazı).
        // Bu aşamada 'this' referansı dışarı sızdırılamaz, ancak alanlara atama yapılabilir.
        if (Float.isNaN(value)) {
            this.bits = (short) 0x7e00;
        } else {
            this.bits = Float.floatToFloat16(value);
        }
        super(); // Nesne bu noktadan sonra tamamen başlatılmış ve değiştirilemez (immutable) kabul edilir.
    }

    public float toFloat() {
        return Float.float16ToFloat(this.bits);
    }

    public Float16 add(Float16 other) {
        // Yeni bir Float16 döndürmek heap allocation yapmaz; 
        // değer doğrudan CPU register'ında skalar olarak taşınır.
        return new Float16(this.toFloat() + other.toFloat());
    }
}

public value record ComplexVector(Float16 real, Float16 imag) {
    // Bellekte iki ayrı nesne işaretçisi yerine, 
    // doğrudan 32-bit (2 x 16-bit) düzleştirilmiş (flattened) veri olarak yerleşir.
    public ComplexVector multiply(ComplexVector other) {
        float r = (real.toFloat() * other.real.toFloat()) - (imag.toFloat() * other.imag.toFloat());
        float i = (real.toFloat() * other.imag.toFloat()) + (imag.toFloat() * other.real.toFloat());
        return new ComplexVector(new Float16(r), new Float16(i));
    }
}

Aşağıdaki karşılaştırma, 1 milyon elemanlı bir ComplexVector[] dizisinin geleneksel JVM ile JDK 28 Valhalla mimarisindeki bellek yerleşim farkını göstermektedir:

"Mimari Not: JEP 401 ile java.lang.Integer, LocalDate, Optional gibi standart kütüphane sınıfları da doğrudan Value Class'a dönüştürülmüştür. Ancak unutulmamalıdır ki referansların null olabilme özelliği (nullability) nedeniyle, büyük nesnelerin yığında düzleştirilmesi bazen ekstra bir 'null-marker' biti gerektirir ve atomiklik (tearing) sınırlarına takılabilir. Tam sıfır-maliyetli düzleştirme, Valhalla'nın bir sonraki adımı olan Null-Restricted Value Types (ComplexVector!) ile tamamlanacaktır."

3. Project Leyden ve JEP 544: Ahead-of-Time (AOT) Kod Derlemesi

Yıllarca Java'nın soğuk başlatma (cold start) problemini çözmek isteyen mimarlar tek bir seçeneğe yönlendirildi: GraalVM Native Image. Ancak GraalVM, "Kapalı Dünya Varsayımı" (Closed-World Assumption) ile çalışır; derleme zamanında tüm sınıfların bilinmesini şart koşar, dinamik sınıf yüklemeyi kısıtlar, yansıma (reflection) için karmaşık JSON yapılandırmaları ister ve en önemlisi, çalışma zamanında profil tabanlı optimizasyon (PGO) yapamadığı için uzun süreli çalışmalarda HotSpot C2 JIT derleyicisinin zirve performansının gerisinde kalabilir.

John Rose ve OpenJDK ekibinin yürüttüğü Project Leyden, bu ikilemi ortadan kaldırmak için kademeli bir strateji izledi:

• JDK 24 (JEP 483): AOT Sınıf Yükleme ve Bağlama (Class Loading & Linking).
• JDK 25 (JEP 514 & 515): Tek komutla AOT önbellek oluşturma ve AOT Metot Profilleme (Method Profiling).
• JDK 26 (JEP 516): ZGC dahil tüm çöp toplayıcılarla çalışan AOT Nesne Önbelleklemesi.
• JDK 28 (JEP 544): Ahead-of-Time Code Compilation (AOT Kod Derlemesi).

JEP 544 Nasıl Çalışır?

JEP 544, Leyden yapbozunun en kritik parçasını tamamlar: Eğitim çalışması (training run) sırasında HotSpot JIT derleyicisi tarafından derlenen yerel makine kodunu (native code) doğrudan AOT önbellek dosyasına (app.aot) kaydeder.

Uygulama üretim ortamında (production) başlatıldığında:

1. JVM sınıfları diskten okuyup ayrıştırmaz; JEP 483 sayesinde önceden bağlanmış (linked) olarak AOT önbelleğinden belleğe haritalar (mmap).
2. Yorumlayıcıda (interpreter) binlerce kez çalışıp ısınmayı beklemez; JEP 544 sayesinde sıcak metotların doğrudan derlenmiş x64/ARM64 makine kodlarını ilk milisaniyede çalıştırmaya başlar.
3. GraalVM'den farklı olarak JVM hala "Açık Dünya" (Open-World) modundadır. Dinamik sınıf yükleme, JFR (Java Flight Recorder), ByteBuddy/CGLIB vekilleri (proxies) kusursuz çalışır. Eğer üretimdeki trafik deseni eğitim çalışmasından farklılaşırsa, HotSpot C2 JIT derleyicisi devreye girerek AOT kodunu çalışma zamanında yeniden optimize (deoptimize & recompile) edebilir.

# JDK 28 — Project Leyden (JEP 544) AOT Eğitim ve Üretim Hattı

# 1. ADIM: Eğitim Çalışması ve AOT Önbelleğinin (Sınıflar + Profiller + Yerel Makine Kodu) Üretilmesi
# JEP 514/544 ile tek komutta hem eğitim yapılır hem de yerel kod derlenip app.aot içine gömülür:
java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf \
     -Dspring.context.exit=onRefresh \
     -jar order-service.jar

java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf \
     -XX:AOTCache=order-service.aot \
     -jar order-service.jar

# (Alternatif Tek-Adım Kısayolu):
java -XX:AOTCacheOutput=order-service.aot \
     -Dspring.context.exit=onRefresh \
     -jar order-service.jar

# 2. ADIM: Üretim Ortamında Anında Zirve Performansla Başlatma
# ZGC Adaptif Yığın Boyutlandırma (JEP 545 & 546) ve AOT Native Code birlikte çalışır:
java -XX:AOTCache=order-service.aot \
     -XX:+UseZGC \
     --enable-preview \
     -jar order-service.jar

OpenJDK ekibinin 2 çekirdekli (JIT derleyicisinin uygulama iş parçacıklarıyla CPU için kıyasıya yarıştığı tipik bir Kubernetes pod'u) Linux/x64 ortamında yaptığı JDK 28 JEP 544 testlerinde, popüler Java çatılarıyla (Spring Boot, Quarkus, Micronaut, Helidon) yazılmış mikroservislerin başlatma sürelerinde %65 ila %80 arasında hızlanma kaydedilmiştir.

4. Project Babylon, HAT ve Panama: Saf Java ile GPU Hızlandırma

Valhalla veriyi CPU önbelleğine göre hizalarken ve Leyden başlatma süresini milisaniyelere indirirken, Project Babylon Java'yı yapay zeka ve heterojen donanım çağına taşıyor. Oracle Kütüphane Mimarı Paul Sandoz liderliğinde yürütülen Babylon, JDK 28 ekosisteminde üç temel bileşeni tek bir boru hattında birleştiriyor:

1. Code Reflection (Kod Yansıması): Standart Java Reflection yalnızca sınıf imzalarını görebilirken, @CodeReflection anotasyonu javac derleyicisinin metot gövdesini Sembolik Kod Modellerine (Symbolic Code Models - SSA IR) dönüştürüp .class dosyasına gömmesini sağlar. Böylece çalışma zamanındaki bir kütüphane, Java metodunun içindeki döngüleri, matematiksel işlemleri ve veri akışını AST/SSA ağacı olarak okuyup dönüştürebilir.
2. HAT (Heterogeneous Accelerator Toolkit): Babylon'un alt projesi olan HAT, bu Kod Modellerini analiz eder ve bunları çalışma zamanında anında CUDA PTX, OpenCL C veya SPIR-V GPU çekirdeklerine (kernels) derler.
3. Project Panama (FFM API) ve Havuzlanmış Arenalar: GPU ile CPU arasındaki veri transferi JNI olmadan, doğrudan Panama'nın MemorySegment ve Arena yapılarıyla gerçekleşir. Üstelik JDK 28, Arena.ofConfined() çağrılarında yerel bellek tahsisini 19 kata kadar hızlandıran havuzlanmış bellek mimarisini (pooled confined arenas) beraberinde getiriyor.

// JDK 28 Ekosistemi — Project Babylon (Code Reflection + HAT) & Panama FFM
import jdk.incubator.code.CodeReflection;
import hat.Accelerator;
import hat.ComputeContext;
import hat.KernelContext;
import hat.buffer.F32Array;
import java.lang.foreign.Arena;

public class GpuAttentionKernel {

    // @CodeReflection: javac bu metodun bytecode'unun yanı sıra 
    // SSA tabanlı sembolik Kod Modelini (Code Model) sınıf dosyasına yazar.
    @CodeReflection
    public static void rmsNormKernel(KernelContext kc, F32Array input, F32Array weight, F32Array output, float eps) {
        int idx = kc.x; // GPU Thread ID (NDRange indeksi)
        if (idx < kc.maxX) {
            float val = input.array(idx);
            float w = weight.array(idx);
            // Bu saf Java aritmetiği HAT tarafından doğrudan CUDA PTX / OpenCL komutlarına derlenir
            output.array(idx, (val / (float) Math.sqrt(val * val + eps)) * w);
        }
    }

    @CodeReflection
    public static void dispatchCompute(ComputeContext cc, F32Array in, F32Array w, F32Array out, int size) {
        cc.dispatchKernel(size, kc -> rmsNormKernel(kc, in, w, out, 1e-5f));
    }

    public static void main(String[] args) {
        // JDK 28: Arena.ofConfined() artık 19x daha hızlı yerel bellek tahsisi sunuyor
        try (var arena = Arena.ofConfined()) {
            Accelerator accelerator = new Accelerator(MethodHandles.lookup());
            int vectorSize = 1_048_576;

            F32Array inBuf  = F32Array.create(accelerator, vectorSize);
            F32Array wBuf   = F32Array.create(accelerator, vectorSize);
            F32Array outBuf = F32Array.create(accelerator, vectorSize);

            // Java metodunu yakala, Code Model üzerinden GPU çekirdeğine dönüştür ve çalıştır
            accelerator.compute(cc -> dispatchCompute(cc, inBuf, wBuf, outBuf, vectorSize));
        }
    }
}

Bu mimari; Valhalla'nın düzleştirilmiş (flattened) veri yapıları, Panama'nın sıfır-kopyalı (zero-copy) yığın dışı belleği ve Babylon'un Code Reflection yeteneği birleştiğinde, Java'nın C++ veya Python/PyTorch bağımlılığı olmadan yerel LLM çıkarımı (örneğin Llama3.java / TornadoVM) ve yüksek performanslı vektör arama motorları koşturabilmesini sağlar.

5. Otonom Çalışma Zamanı: ZGC (JEP 545 & 546), Loom (JEP 543) ve Yerleşik JSON (JEP 540)

JDK 28 yalnızca büyük üçlüyle sınırlı kalmıyor; kurumsal üretim ortamlarındaki operasyonel sürtünmeyi sıfıra indiren kritik JEP'leri de devreye alıyor:

JEP 545 & JEP 546: ZGC'de Otonom ve Hızlı Bellek Yönetimi

Yıllardır DevOps ve SRE ekiplerinin en büyük kabusu, konteyner ortamlarında -Xms ve -Xmx parametrelerini ayarlamaktı. -Xmx'i çok yüksek verirseniz JVM boş belleği işletim sistemine geri vermez ve komşu süreçleri aç bırakır; çok düşük verirseniz GC fırtınaları ve OutOfMemoryError yaşanır.

• JEP 546 (Adaptive Heap Sizing for ZGC): ZGC artık makinedeki boş fiziksel belleği, uygulamanın tahsis hızını (allocation rate) ve aynı sunucudaki komşu uygulamaların bellek ihtiyacını gerçek zamanlı izleyerek yığın (heap) boyutunu otonom olarak büyütüp küçültüyor.
• JEP 545 (Faster Startup and Warmup with ZGC): ZGC'nin uygulama başlangıcında fiziksel belleği işletim sisteminden talep etme ve hazırlama (memory unmapping/mapping) algoritmalarını optimize ederek soğuk başlatma gecikmesini ortadan kaldırıyor.

JEP 543: Structured Concurrency (Nihai Sürüm) ve JEP 540: Simple JSON API

• JEP 543: Project Loom'un Sanal İş Parçacıkları (Virtual Threads) ve Scoped Values'dan sonraki üçüncü ayağı olan Yapılandırılmış Eşzamanlılık (Structured Concurrency), uzun süren önizleme turlarının ardından JDK 28'de nihai (final) statüsüne kavuşuyor. Farklı sanal iş parçacıklarına bölünen alt görevler artık tek bir atomik iş birimi olarak yönetiliyor; bir alt görev hata verdiğinde diğerlerinin otomatik iptal edilmesi (short-circuiting) ve iş parçacığı sızıntılarının (thread leaks) önlenmesi dil seviyesinde garanti altına alınıyor.
• JEP 540 (Simple JSON API - Incubator): Basit konfigürasyon okuma veya mikroservis/ajan iletişimi için devasa üçüncü parti kütüphaneleri (Jackson, Gson) projeye dahil etme zorunluluğu sona eriyor. JDK 28, RFC 8259 standardıyla tam uyumlu, hafif ve değişmez (immutable) veri yapılarına dayanan yerleşik bir JSON ayrıştırma ve üretme API'sini çekirdek kütüphaneye ekliyor.

6. Mühendislik ve Mimari Çıkarımlar: Sistemlerimizi Nasıl Tasarlamalıyız?

JDK 28 ile şekillenen bu yeni JVM mimarisi, kıdemli yazılım mühendisleri ve sistem mimarları için tasarım alışkanlıklarını kökten değiştirecek net mesajlar içeriyor:

1. "Primitive Array" Hack'lerini Bırakın, Alan Modellerine Dönün: Yıllarca finans, oyun motoru ve yüksek frekanslı ticaret (HFT) sistemlerinde çöp toplayıcı baskısından kaçmak için nesne yönelimli tasarımdan feragat edildi; Order nesneleri yerine paralel long[] orderIds, double[] prices dizileri kullanıldı. JEP 401 Value Classes ile artık hem zengin alan odaklı (Domain-Driven) sınıflar yazabilir hem de bellekte ilkel dizilerle birebir aynı düzleştirilmiş (flattened) veri yoğunluğunu elde edebilirsiniz.
2. CI/CD Boru Hatlarına "AOT Eğitim Aşaması" Ekleyin: Project Leyden (JEP 544), GraalVM'in derleme süresi ve uyumluluk maliyetleri olmadan GraalVM seviyesinde başlatma hızları sunuyor. Ancak bu hızdan faydalanmak için Docker imajı oluşturma (build) aşamasına, uygulamanın hedef mimaride (x64 veya ARM64) kısa bir duman testi (smoke test / training run) çalıştırıp .aot önbellek dosyasını imaja gömeceği yeni bir CI/CD adımı eklenmelidir.
3. Kimliğe Duyarlı Kodları Şimdiden Temizleyin: Kod tabanınızdaki new Integer(), synchronized(valueBasedObject) veya değer nesneleri üzerinde referans eşitliği (==) varsayımlarını derhal temizleyin. JDK 28 derleyicisi ve çalışma zamanı, değer sınıfları üzerinde kimlik gerektiren işlemler yapıldığında doğrudan IdentityException fırlatmaktadır.
4. Yapay Zeka İş Yüklerinde Poliglot Karmaşasını Sorgulayın: Sırf vektör hesaplaması veya yerel model çıkarımı yapmak için Java mikroservislerinin yanına Python yan-arabaları (sidecars) dikmek ve gRPC serileştirme maliyeti ödemek zorunda değilsiniz. Project Panama FFM, Vector API ve Project Babylon (HAT) üçlüsü, JVM'i birinci sınıf bir yerel yapay zeka çalışma zamanına dönüştürmüştür.

Ron Pressler'ın da vurguladığı gibi, içinden geçtiğimiz dönem "Çalışma Zamanının Yılı" (The Year of the Runtime) olarak tarihe geçiyor. JDK 28, Java'nın 30 yıllık geriye dönük uyumluluk mirasını korurken, modern silikonun (CPU önbellek hiyerarşileri ve GPU hızlandırıcıları) talep ettiği tüm düşük seviyeli yetenekleri doğrudan geliştiricinin parmak uçlarına getiriyor. Nesne kimliğinin opsiyonel olduğu, ısınma süresinin sıfırlandığı ve bytecode duvarının yıkıldığı yeni nesil JVM çağına hoş geldiniz.