"Her Şeyi Rust İle Yeniden Yaz" Mitine JVM Tokadı: Kotlin/Java vs. Rust Kıyaslaması, Paul Sandoz’dan 4 Katmanlı AI Mimarisi, JEP 540 RFC 8259 JSON ve Jenkins’ten AI-Destekli CI’a Evrim

Yazılım mühendisliği endüstrisi belirli periyotlarla kolektif bir hipnoza girer. Son birkaç yılın en güçlü hipnozu ise şüphesiz "Rewrite Everything in Rust" (Her Şeyi Rust İle Yeniden Yaz) akımı ve "Yapay zeka sadece Python ve C++'ın oyun alanıdır" yanılgısıydı. Ancak üretim ortamlarının (production) acımasız gerçekliği, sosyal medya kıyaslamalarından çok farklı işler. Kod yazmanın kendisi yapay zeka ajanları tarafından metalaştırıldıkça, mühendislik ağırlık merkezi sözdiziminden (syntax) çalışma zamanı (runtime) fiziğine ve sistem mimarisine kayıyor.

Bu sabah TastutanLabs Mühendislik Bülteni'nde; hem OpenJDK (Inside.java) cephesinden gelen Devoxx Belgium 2026 kaynaklı dört dev mimari sunumu hem de Spring.io ekosisteminde Josh Long'un ev sahipliğinde gerçekleşen ezber bozan tartışmaları ve haftalık ekosistem bültenlerini tek bir potada eritiyoruz. Kahveniz hazırsa, JVM'in kaputunun altına iniyoruz.

1. "Java/Kotlin, Rust'tan Daha Performanslı Olabilir mi?" — Andrew Lombardi Rakamlarla Masada

Spring ekosisteminin sesi Josh Long, A Bootiful Podcast'in son bölümünde topluluğun kıdemli isimlerinden Andrew Lombardi'yi ağırladı: "Can Java be more performant than Rust? Andrew Lombardi has the numbers". Bu bölüm, teknoloji dünyasında büyük gürültü koparan bir "Rust ile yeniden yazım" (Rust rewrite) vakasına karşı yapılmış en zekice mühendislik deneylerinden birini mercek altına alıyor.

Hikaye tanıdık: Bir ekip mevcut uygulamasını Rust ile baştan yazar, devasa performans artışı elde ettiğini iddia eden bir benchmark yayınlar ve tüm internet "JVM öldü, yaşasın sıfır maliyetli soyutlamalar (zero-cost abstractions)" diye bayram eder. Uzun yıllardır JVM ve Kotlin ekosisteminde büyük ölçekli sistemler inşa eden Andrew Lombardi ise bu iddiayı test etmeye karar verir. Üstelik eskiden aylarca sürecek bu yeniden yazım (porting) işlemini, AI destekli kodlama araçlarını sürücü koltuğuna oturtarak pratik bir hafta sonu meydan okumasına dönüştürür.

Benchmark Tuzakları ve C2 JIT Gerçeği

Lombardi'nin gerçek bir uygulamayı Kotlin/JVM'e port ederek Rust versiyonuyla kafa kafaya çarpıştırdığı deneyde ortaya çıkan bulgular, her kıdemli mimarın duvara asması gereken dersler içeriyor:

1. Benchmarking Yanılsamaları ve Önbellekleme (Caching) Sürprizleri: Çoğu "Rust 10 kat daha hızlı" blog yazısında aslında eski mimarideki kötü I/O desenleri veya eksik önbellekleme, yeni dilde düzeltildiği için hız artışı dile (Rust'a) mal edilir. Lombardi, framework denkliği (framework parity) sağlandığında ve önbellekleme katmanları eşitlendiğinde aradaki yapay farkın nasıl buharlaştığını rakamlarla ortaya koyuyor.
2. Statik Derleme (LLVM) vs. Profil Güdümlü JIT (C2): Rust derleme zamanında (compile-time) muazzam optimizasyonlar yapar; ancak HotSpot JVM'in C2 JIT derleyicisi çalışma zamanında (runtime) gerçek trafik profillerini görerek spekülatif optimizasyonlar (speculative inlining, escape analysis, loop unrolling) gerçekleştirir. Uzun süreli çalışan (long-running) sunucu iş yüklerinde, JVM'in sıcak kod yollarını (hot paths) donanım mimarisine göre dinamik olarak bükmesi, statik derlenmiş ikili dosyaları (binaries) yakalayıp geçebilmesini sağlar.
3. AI ile Yeniden Yazım Ekonomisi ve Okunabilirlik: Lombardi, dönüşüm sürecindeki token maliyetlerini (token costs) ve bellek ödünleşimlerini (memory tradeoffs) şeffafça paylaşırken çok kritik bir noktaya parmak basıyor: Büyük ölçekli kurumsal sistemlerde Kotlin ve modern Java'nın tip sistemi (type system) ile okunabilirliği, hem insan mühendislerin hem de AI ajanlarının kodu bakım yapılabilir şekilde evrimleştirmesini Rust'ın borrow-checker karmaşasına kıyasla çok daha verimli kılıyor.

"Mimari Not: Bir sistemi A dilinden B diline geçirdiğinizde elde ettiğiniz performans artışının %80'i genellikle dilin kendisinden değil, sistemi ikinci kez yazarken ilk seferde yaptığınız mimari hataları temizlemenizden kaynaklanır. JVM'i doğru bellek ve eşzamanlılık modeliyle kurguladığınızda, C/Rust seviyesinde throughput elde etmek bir istisna değil, kuraldır."

2. Paul Sandoz ve Ron Pressler Vizyonu: "Runtime Yılı"nda Java Yapay Zeka Dünyasına Nasıl Oturuyor?

Inside.java'da bu hafta yayınlanan iki temel sunum aslında aynı madalyonun iki yüzünü oluşturuyor: OpenJDK Mimarı Ron Pressler'in Devoxx Belgium 2026 açılış konuşması "Java - The Year of the Runtime!" ve hemen ardından Paul Sandoz'un yayınlanan "How Does Java Fit Into the World of AI—and How Can It Become an Even Better Fit?" başlıklı kapsamlı teknik analizi.

Ron Pressler'in tespiti son derece keskin: AI kodlama ajanları (coding agents) sözdizimi yazmayı ucuzlattıkça, dillerin yüzeysel "syntactic sugar" özellikleri önemini yitiriyor. Artık asıl darboğaz çalışma zamanı performansı (runtime performance), gözlemlenebilirlik (observability), çöp toplama (GC) determinizmi ve operasyonel kararlılık. İşte Valhalla, Leyden ve Lilliput projeleriyle donatılmış JVM tam bu noktada rakipsizleşiyor.

Peki ya doğrudan Yapay Zeka iş yükleri? Paul Sandoz, AI mimarisini dört ayrı katmana ayırarak Java'nın mevcut konumunu ve gelecekteki sıçramasını haritalandırıyor:

Project Babylon, Code Reflection ve "Project Detroit" Sürprizi

Sandoz'un sunumundaki en heyecan verici teknik detay, JEP aday (candidate) statüsüne doğru ilerleyen Code Reflection (Kod Yansıması) mimarisi. Geleneksel Java Reflection sadece sınıf, metot ve alan (field) imzalarını görebilirken; Code Reflection bir Java metodu veya lambda ifadesinin içindeki kodu sembolik bir "Code Model" (Soyut Sözdizimi Ağacına / AST'ye benzer bir SSA formu) olarak çalışma zamanında incelemenize ve dönüştürmenize olanak tanır.

Bu sayede HAT (Heterogeneous Accelerator Toolkit), yazdığınız taşınabilir saf Java kodunu alıp OpenCL, CUDA veya SPIR-V GPU shader koduna ya da makine öğrenimi için türevlenebilir (differentiable) koda derleyebiliyor. Ayrıca Sandoz, Panama ve Valhalla'nın yanında Project Detroit (Java-Python birlikte çalışabilirliği / interop) gibi tamamlayıcı yapı taşlarına da dikkat çekerek Java'nın yerel AI kütüphaneleriyle arasındaki duvarları nasıl yıktığını gösteriyor:

// Project Babylon & Code Reflection: Saf Java'dan GPU Kernel'ına ve Türevlenebilir Koda
import jdk.incubator.code.CodeReflection;
import jdk.incubator.code.Op;
import jdk.incubator.code.type.CoreOp;
import hat.ComputeContext;
import hat.buffer.F32Array;

public class BabylonAiInferenceKernel {

    // @CodeReflection anotasyonu derleyiciye bu metodun sembolik "Code Model"ini 
    // sınıf dosyasında (classfile) saklaması talimatını verir.
    @CodeReflection
    public static void rmsNormKernel(KernelContext kc, F32Array weights, F32Array activations, float epsilon) {
        int idx = kc.x;
        if (idx < activations.length()) {
            float val = activations.array(idx);
            float w = weights.array(idx);
            // Bu saf Java aritmetiği, HAT tarafından doğrudan OpenCL/PTX GPU komutlarına çevrilir!
            activations.array(idx, (val / (float) Math.sqrt(val * val + epsilon)) * w);
        }
    }

    public static void inspectAndDispatch(ComputeContext cc, F32Array w, F32Array act) throws Exception {
        // Çalışma zamanında metodun sembolik kod modelini (AST/SSA) çekiyoruz:
        var method = BabylonAiInferenceKernel.class.getDeclaredMethod(
                "rmsNormKernel", KernelContext.class, F32Array.class, F32Array.class, float.class);
        
        CoreOp.FuncOp codeModel = Op.ofMethod(method).orElseThrow();
        System.out.println("Sembolik Kod Modeli (SSA):\n" + codeModel.toText());

        // HAT üzerinden GPU kuyruğuna gönderim:
        cc.dispatchKernel(act.length(), kc -> rmsNormKernel(kc, w, act, 1e-5f));
    }
}

3. Alan Bateman ve Viktor Klang Sahnede: JEP 540 ("Everyday JSON") ve Structured Concurrency'nin Alt Seviye Geleceği

OpenJDK'nın çekirdek kütüphaneler ve eşzamanlılık mimarları Alan Bateman ve Viktor Klang, bu hafta Inside.java'da yayınlanan iki ayrı derinlemesine oturumla ("Everyday JSON in Java" ve "Structured Concurrency Looms") JDK 28 ve sonrasının standart kütüphane tasarım felsefesini ortaya koydular.

3.1. Everyday JSON in Java (JEP 540): Neden "Agresif Derecede Mütevazı" ve Katı?

JDK 28 için kuluçka (incubator) aşamasında hedeflenen JEP 540, Java'ya nihayet yerleşik bir JSON ayrıştırıcı (parser) getiriyor. Ancak Bateman ve Klang konuşmalarında son derece dürüst bir sınır çiziyorlar: Bu API bir Jackson veya Gson alternatifi değildir! Bir yapılandırma dosyasını (config) okumak, basit bir HTTP JSON yükü (payload) oluşturmak veya zaten JSON üreten JDK Thread Dump'larını ve JFR (JDK Flight Recorder) kayıtlarını harici bir bağımlılık (dependency) eklemeden ayrıştırmak için tasarlanmıştır. ("Tek bir sandalyeyi taşımak için nakliye şirketi kiralamak istemediğiniz" senaryolar için).

JEP 540'ın mimarisinde öne çıkan 3 kritik karar var:

1. Veri Odaklı Programlama (Data-Oriented Programming): API, sealed (mühürlü) bir JSON değer hiyerarşisi (JsonValue -> JsonString, JsonNumber, JsonBoolean, JsonNull, JsonObject, JsonArray) üzerine kurulu. Gezinme için parse, toDisplayString, get, tryGet ve tryValue sunuluyor.
2. Postel Yasası'nın Reddi ve Katı RFC 8259 Uyumu: En keskin tasarım kararı burada! Ayrıştırıcı yalnızca RFC 8259 standardını kabul ediyor ve hiçbir esnekliğe izin vermiyor. Yorum satırı (comments) yok, sonda unutulan virgül (trailing comma) yok, tekrarlanan anahtar isimleri (duplicate member names) yok. İki farklı ayrıştırıcının aynı JSON yükünü farklı yorumlamasından doğan güvenlik ve hata ayıklama kabuslarını önlemek için "sıfır tolerans" seçilmiş.
3. Bilinçli Eksikler: İlk sürümde doğrudan Record-to-JSON nesne eşlemesi (data-binding) veya çekirdek yüzeyde yerleşik BigDecimal dönüşümü bulunmuyor; odak noktası tamamen düşük sürtünmeli ağaç (tree) navigasyonu ve pattern matching uyumu.

3.2. Structured Concurrency Looms: Yüksek Seviye API'nin Altındaki Yeni Motor

İkilinin ikinci sunumu olan "Structured Concurrency Looms", JDK 21'deki Sanal İş Parçacıklarının (Virtual Threads) ardından Project Loom'un en büyük ikinci adımı olan Yapılandırılmış Eşzamanlılığı (StructuredTaskScope) ele alıyor. JDK 28'de kalıcı (permanent/final) hale gelmesi teklif edilen bu özellik, bir ana görev ve onun çatalladığı (fork) alt görevleri tek bir iş birimi (single unit of work) olarak ele alıyor.

Konuşmada vurgulanan en önemli yenilikler şunlar:

• Takılıp kalan (leaked) thread'leri tarihe gömen garantili close() temizliği ve iş parçacığı kesmesi (thread interruption) tabanlı otomatik iptal (cancellation) mekanizması.
• Eklenti mimarisine sahip birleştiriciler (Pluggable Joiners): allSuccessfulOrThrow, anySuccessfulOrThrow, allUntil gibi politikalar ve kapsam yaşam döngüsüne (open/join) bağlı zaman aşımları (configurable timeouts).
• Yeni Düşük Seviyeli (Lower-Level) API Sinyali: Bateman ve Klang, mevcut yüksek seviyeli StructuredTaskScope soyutlamasının hemen altında çalışan yeni bir düşük seviyeli eşzamanlılık API'sinin ilk sinyallerini verdiler. Bu alt katman, gelecekte özel eşzamanlılık çerçeveleri (custom concurrency frameworks) yazacak kütüphane geliştiricileri için temel taşı olacak.

Gelinen noktada JEP 540 (Everyday JSON) ile Structured Concurrency'nin bir ajanik mikroserviste nasıl kusursuz birleştiğini aşağıdaki kod örneğinde görebilirsiniz:

import java.util.concurrent.StructuredTaskScope;
import java.util.concurrent.StructuredTaskScope.Joiner;
import java.time.Duration;
import jdk.incubator.json.Json;
import jdk.incubator.json.JsonObject;
import jdk.incubator.json.JsonNumber;

public class AgentTelemetryAggregator {

    public record SystemHealth(double avgTemp, String activeThreadCount) {}

    public SystemHealth fetchAndParseMetrics() throws InterruptedException {
        // Structured Concurrency: Tüm alt görevler tek bir yaşam döngüsüne bağlıdır
        try (var scope = StructuredTaskScope.open(
                Joiner.allSuccessfulOrThrow(),
                cf -> cf.withTimeout(Duration.ofSeconds(2)))) {

            var weatherTask = scope.fork(this::fetchWeatherApiJson);
            var jfrDumpTask = scope.fork(this::captureLocalJfrSummaryJson);

            // Her iki görev tamamlanana veya biri hata verip diğerini iptal edene kadar bekle
            scope.join();

            // JEP 540 (Everyday JSON): Harici Jackson bağımlılığı olmadan katı RFC 8259 ayrıştırma
            var weatherRoot = (JsonObject) Json.parse(weatherTask.get());
            var jfrRoot = (JsonObject) Json.parse(jfrDumpTask.get());

            // Veri Odaklı Programlama (DOP) ve Pattern Matching ile güvenli gezinme
            double temp = switch (weatherRoot.tryGet("currentTemp").orElseThrow()) {
                case JsonNumber n -> n.toDouble();
                default -> throw new IllegalStateException("Beklenmeyen JSON tipi!");
            };

            String threads = jfrRoot.get("virtualThreadsActive").toDisplayString();
            return new SystemHealth(temp, threads);
        }
    }

    private String fetchWeatherApiJson() {
        // RFC 8259 uyumlu saf JSON (Yorum satırı veya trailing comma içeremez!)
        return "{\"currentTemp\": 22.4, \"unit\": \"C\"}";
    }

    private String captureLocalJfrSummaryJson() {
        return "{\"virtualThreadsActive\": \"1420\", \"pinnedEvents\": 0}";
    }
}

"Mimari Not: JDK kendi iç araçlarında (JFR ve JSON Thread Dumps — üstelik bu dump'lar artık StructuredTaskScope içindeki ebeveyn-çocuk görev hiyerarşisini de koruyor!) zaten JSON üretiyordu. JEP 540 ile JDK'nın ürettiği telemetri verisini yine sıfır bağımlılıkla JDK içinde tüketebilmek, özellikle kendi kendini izleyen (self-observing) otonom ajan mimarileri için muazzam bir kazanımdır."

4. Jenkins'in Babası Kohsuke Kawaguchi ile Mühendislik Retrospektifi ve Spring Ekosisteminde Haftanın Özeti

Sabah bültenimizin son durağında tekrar Spring.io resmi bloguna dönüyoruz. Josh Long'un hem 6 Ekim hem de 13 Ekim 2026 tarihli "This Week in Spring" bültenleri ile efsanevi Java mühendisi Kohsuke Kawaguchi'yi konuk ettiği özel podcast bölümü, ekosistemin nereden gelip nereye evrildiğini gözler önüne seriyor.

4.1. Kohsuke Kawaguchi: JAXB ve Kırık Build'lerden Hudson/Jenkins'e, Oradan AI Destekli CI'a

Modern yazılım tarihinde Kohsuke Kawaguchi kadar günlük geliştirici pratiklerini derinden etkilemiş çok az mühendis vardır. Bay Area'daki bir Java belgeseli gösteriminde gerçekleşen tesadüfi bir buluşmayla başlayan podcast sohbeti, Java'nın görünmez kahramanlık hikayelerini gün yüzüne çıkarıyor:

• Sun Microsystems Yılları ve "Gerçek Dünya" Araçları: Kawaguchi'nin Sun'da JDK içerisindeki XML ve web servisleri altyapısını (JAXB, XML şema doğrulayıcıları) inşa ettiği günler... Ancak onu asıl farklı kılan, Java'yı masaüstünde ve Windows ortamlarında pratik hale getiren Com4J ve Java süreçlerini işletim sistemi servisine dönüştüren daemonization araçları gibi "dağınık gerçek dünya entegrasyon" sorunlarını çözen tutkulu yan projeleriydi.
• Kişisel Bir Hayal Kırıklığından Doğan Devrim (Hudson -> Jenkins): Ekip arkadaşlarının sürekli build'i kıran kodlar göndermesinden (broken builds) duyduğu kişisel bıkkınlığın önce Hudson'a, ardından tarihin en önemli Sürekli Entegrasyon (CI) platformu olan Jenkins'e nasıl dönüştüğünü kendi ağzından dinliyoruz. Jenkins'in neden bu kadar hızlı yayıldığının cevabı mimarisinde gizli: Açıklık ve modülerlik felsefesini yansıtan eklenti tabanlı (plugin-based) çekirdek mimari.
• Launchable ve CloudBees: Kawaguchi'nin vizyonu sadece kod derlemekle kalmadı; devasa test paketlerinin (test suites) CI/CD hatlarında yarattığı darboğazı makine öğrenimi ile çözmek için kurduğu Launchable (sadece değişen kodla en ilişkili testleri seçip koşturan akıllı test yürütme motoru) ve bu teknolojinin tekrar CloudBees bünyesine katılma süreci, modern AI-destekli DevOps'un öncüsü niteliğinde.

4.2. "This Week in Spring" (6 & 13 Ekim 2026): Ekosistemde Neler Oluyor?

Son iki haftanın This Week in Spring özetlerine ve bağlantılı duyurulara baktığımızda, Spring ekosisteminin 2026 sonbaharında tam gaz yeni nesil sürümlere geçtiğini görüyoruz:

• Yeni Kilometre Taşları: Spring Boot 4.2.0-M2, Spring Security 7.2.0-M2, Spring Batch 6.1.0-M2 ve kod adı "Paddington" olan Spring Cloud 2026.0.0-M1 sürümleri ekosistemin omurgasını JDK 27/28 özellikleriyle hizalıyor.
• Spring AI 2.1.0-M1 ve Modüler RAG: Özellikle Spring AI Modular RAG mimarisindeki "Retrieve More, Keep Only What Answers" (Daha fazla getir, yalnızca soruyu yanıtlayanı tut) yaklaşımı, kurumsal RAG boru hatlarında bağlam penceresi (context window) kirliliğini ve token maliyetlerini düşüren tip-güvenli (type-safe) yeni filtreleme mekanizmalarını devreye sokuyor.

Mühendisler ve Sistem Mimarları İçin Sabah Çıkarımları

Bugün incelediğimiz 8 ayrı haber kaynağının kesişim kümesi bize çok net bir mühendislik rotası çiziyor:

1. Moda Akımlarla Değil, Telemetriyle Mimari Karar Alın: Andrew Lombardi'nin Kotlin/JVM vs. Rust deneyinin kanıtladığı gibi, performans darboğazlarının çözümü tüm kod tabanını başka bir dile taşımak değildir. Önce önbellekleme katmanınızı, I/O modelinizi (Virtual Threads) ve GC/JIT parametrelerinizi doğru kurgulayın.
2. Ajanik Sistemlerde Standart JDK Yeteneklerini Maksimuma Çıkarın: JEP 540 (Everyday JSON) ve Structured Concurrency (JEP 543/JDK 28) ikilisi, dış bağımlılıkları minimuma indirilmiş, yüksek eşzamanlıklı ve kendi kendini denetleyebilen hafif (lightweight) mikroservisler/ajanlar yazmak için ihtiyacınız olan her şeyi doğrudan java.* / jdk.* isim alanı altında sunuyor.
3. Java'nın GPU Çağına Hazırlanın: Paul Sandoz'un vurguladığı Project Babylon (Code Reflection & HAT) kuluçka aşamasına girerken, Java artık sadece LLM API'lerini çağıran bir "orkestratör" değil; doğrudan GPU üzerinde çıkarım (inference) ve diferansiyel hesaplama yapabilen tam katmanlı bir AI platformuna dönüşüyor.

Kodun yapay zeka tarafından saniyeler içinde üretildiği bir dünyada, çalışma zamanına (JVM Runtime) hükmeden mimarlar oyunu kazanmaya devam edecek.