2 MB Yığınla 100ms ZGC Başlangıcı ve Yerleşik JSON Çağı: JDK 28’de JEP 545, JEP 546 ve JEP 540 (Simple JSON API) Mimarisi

OpenJDK Ekosisteminde İki Asırlık İkilemin Çözümü: Bellek Başlangıcı ve Sıfır-Bağımlılıklı Veri İşleme

Kurumsal Java ve OpenJDK dünyasında son haftanın en önemli mühendislik gelişmeleri, yıllardır JVM mimarlarının masasında bekleyen iki temel soruna odaklanıyor: Düşük gecikmeli çöp toplayıcı ZGC'de hızlı başlangıç (startup) ile hızlı ısınma (warmup) arasındaki ödünleşim ve basit JSON işlemleri için bile devasa üçüncü taraf kütüphanelere (Jackson, Gson) bağımlı kalma zorunluluğu.

Inside.java ve Devoxx Belgium sahnesinde paylaşılan JEP 545 (Faster Startup and Warmup with ZGC), JEP 546 (Adaptive Heap Sizing for ZGC) ve Viktor Klang ile Alan Bateman tarafından detaylandırılan JEP 540 (Simple JSON API — Incubator), JDK 28'in bulut-yerli mikroservisler ve veri odaklı programlama (DOP) için nasıl yeniden şekillendiğini gözler önüne sermektedir.

1. JEP 545 ve JEP 546: ZGC’de "Soğuk Başlangıç vs. Isınma" İkileminin Sonu

Milisaniye altı (sub-millisecond) duraksama süreleriyle kurumsal Java'nın gözdesi haline gelen Z Garbage Collector (ZGC), bugüne kadar bellek tahsisinde zorlu bir mimari ikilem barındırıyordu:

1. Büyük Başlangıç Yığını (-Xms = -Xmx) Senaryosu: Üretim ortamında yeniden boyutlandırma maliyeti yaşamamak için başlangıç yığını büyük tutulduğunda, JVM ayağa kalkarken tüm fiziksel bellek sayfalarını işletim sisteminden talep ediyor, sanal adres uzayına eşliyor (mapping) ve sayfa ön-dokunuşu (-XX:+AlwaysPreTouch) yapıyordu. Bu durum soğuk başlangıç (cold start) süresini saniyelere uzatıyordu.
2. Küçük Başlangıç Yığını Senaryosu: Hızlı başlangıç için -Xms küçük verildiğinde ise uygulama ilk trafik dalgasını aldığında (warmup evresi) ZGC sürekli bellek genişletme ve yeniden tahsis (reallocation) darboğazına giriyor, erken dönem işlem gecikmeleri (tail latency) fırlıyordu.

JEP 545 Bu Darboğazı Nasıl Çözüyor?

JDK 28 için hedeflenen JEP 545, ZGC'nin işletim sistemi çekirdeğiyle ve fiziksel bellekle kurduğu ilişkiyi baştan aşağı değiştirmektedir:

JEP 545 ile ZGC artık yaklaşık 2 MB gibi minimal bir başlangıç yığınıyla neredeyse anında (~100 ms mertebesinde) ayağa kalkar. Uygulama nesne ürettikçe yığın arka planda agresif ve eşzamanlı (concurrent) olarak genişletilir; sayfa ön-dokunuşları ise uygulama iş parçacıklarını (application threads) durdurmadan arka plan ZGC işçileri tarafından artımlı olarak tamamlanır.

2. "Everyday JSON in Java" ve JEP 540: Veri Odaklı Programlama (DOP) İle Yerleşik JSON API

Devoxx Belgium'da Java Platform Grubu baş mimarlarından Viktor Klang ve Alan Bateman tarafından sunulan "Everyday JSON in Java" oturumu, Java ekosisteminin en çok tartışılan konularından birine netlik kazandırdı: JEP 540 (Simple JSON API — Incubator).

Neden Jackson Varken Yerleşik Bir JSON API'sine İhtiyaç Var?

Klang ve Bateman sunumda çok önemli bir mimari sınır çizmektedir: JEP 540, Jackson veya Gson gibi kapsamlı veri bağlama (data-binding) çatılarının yerini almak için tasarlanmamıştır. Ancak günlük mühendislikte binlerce senaryoda (küçük bir yapılandırma dosyası okumak, bir LLM/OpenAI/Gemini REST API'sine 10 satırlık istek atmak, JFR telemetri çıktısını ayrıştırmak veya JBang betiği yazmak) sırf JSON okumak için projeye megabaytlarca harici bağımlılık ve yansıma (reflection) kuralları eklemek orantısız bir yük oluşturmaktadır.

JEP 540, geleneksel nesne-ilişkisel eşleme veya anotasyon büyüsü yerine Veri Odaklı Programlama (Data-Oriented Programming — DOP) prensiplerini kullanır:

• Mühürlü (Sealed) Değer Hiyerarşisi: JSON veri tipleri (JsonObject, JsonArray, JsonString, JsonNumber, JsonBoolean, JsonNull) değişmez (immutable) ve mühürlü bir hiyerarşi olarak modellenir.
• Pattern Matching ve Record Deconstruction: Yansıma (reflection) ile sınıf alanlarına gizlice değer atamak yerine, Java'nın modern switch kalıp eşleme ve yapı sökümü (deconstruction) yetenekleriyle tip güvenli ayrıştırma yapılır.
• Tavizsiz RFC 8259 Uyumu: Farklı ayrıştırıcılar arasındaki güvenlik açıklarını (JSON interoperability vulnerabilities) önlemek adına yorum satırlarına veya sonda unutulan virgüllere (trailing commas) izin vermeyen katı bir RFC 8259 doğrulayıcısı içerir.

// JEP 540 (Incubator) yaklaşımı: Yansıma (Reflection) olmadan Pattern Matching ile JSON işleme
import jdk.incubator.json.Json;
import jdk.incubator.json.JsonValue;
import jdk.incubator.json.JsonObject;
import jdk.incubator.json.JsonNumber;
import jdk.incubator.json.JsonString;

public class TelemetryPayloadInspect {
    public static String inspectStatus(String rawJson) {
        JsonValue root = Json.parse(rawJson);

        return switch (root) {
            case JsonObject(var members) when members.get("status") instanceof JsonString(String code)
                && members.get("latencyMs") instanceof JsonNumber(Number ms) -> {
                if (ms.doubleValue() > 250.0) {
                    yield "SLA_BREACH: " + code + " (" + ms + "ms)";
                }
                yield "HEALTHY: " + code;
            }
            default -> "INVALID_SCHEMA";
        };
    }
}

3. Yapay Zeka Çağında Java’nın Konumu ve CI/CD Otomasyonu

Haftanın bülteninde öne çıkan diğer iki başlık ise "How Does Java Fit Into the World of AI?" analizi ve Jenkins'in yaratıcısı efsanevi Java geliştiricisi Kohsuke Kawaguchi'nin Spring podcast'indeki değerlendirmeleridir:

1. Yapay Zeka İçin JVM'in Evrimi: Project Panama (FFM API), Vector API, Project Babylon (Code Reflection / GPU çekirdek üretimi) ve JEP 540 gibi hafif veri API'leri birleştiğinde; Java artık yalnızca arka uç iş mantığını yürüten bir dil değil, yerel LLM çıkarımı ve ajan orkestrasyonunu sıfır harici köprüyle yürüten birinci sınıf bir AI çalışma zamanına dönüşmektedir.
2. Tahmine Dayalı Test Seçimi (Predictive Test Selection): Kawaguchi'nin vurguladığı üzere, kurumsal Java depolarında kod üretimi yapay zeka ajanlarıyla hızlandıkça asıl darboğaz CI/CD derleme ve test sürelerine kaymaktadır. Her commit'te binlerce entegrasyon testini körü körüne koşturmak yerine, değişen bayt kodu grafiğini analiz ederek yalnızca kırılma olasılığı en yüksek %5'lik test alt kümesini ilk aşamada çalıştıran akıllı test orkestrasyonu kurumsal ekipler için zorunlu hale gelmiştir.

4. Kurumsal Java Mimarları İçin Özet Karar Noktaları

• ZGC Geçişini Hızlandırın: JEP 545 ve JEP 546 ile ZGC'nin konteyner ve sunucusuz (serverless) ortamlardaki soğuk başlangıç dezavantajı ortadan kalkmaktadır; düşük gecikmeli servislerde G1GC'den Generational ZGC'ye geçiş maliyetleri minimuma inmiştir.
• Mikro-Araçlarda Veri Odaklı Programlamayı (DOP) Benimseyin: Hafif HTTP istemcileri, CLI araçları ve içsel telemetri ayrıştırıcılarında ağır veri bağlama (data-binding) kütüphaneleri yerine mühürlü tipler ve Pattern Matching tabanlı yaklaşımlara yönelin.