Ana Sayfa/Yapay Zeka & Gelecek
Yapay Zeka & Gelecek·17 Ekim 2026·9 dk okuma

TCP Darboğazından io_uring ve QUIC Çağına: Quarkus 4.0.0.Beta1, Vert.x 5, Hibernate ORM 8 ve Yeni Nesil Bulut-Yerli Java Mimarisi

Ekim 2026 itibarıyla yayınlanan Quarkus 4.0.0.Beta1; Java 21 tabanı, Netty 4.2 ve Vert.x 5.x ağ omurgası, yerel io_uring taşıyıcıları, QUIC/HTTP/3 desteği, Hibernate ORM 8, Jackson 3 ve birleşik Observation API ile kurumsal Java yığınını çekirdekten yeniden inşa ediyor.

TCP Darboğazından io_uring ve QUIC Çağına: Quarkus 4.0.0.Beta1, Vert.x 5, Hibernate ORM 8 ve Yeni Nesil Bulut-Yerli Java Mimarisi

Bulut-yerli (cloud-native) mikroservis mimarilerinde bir uygulama çatısının (framework) ömrünü belirleyen temel unsur, işletim sistemi çekirdeği ve ağ protokollerindeki evrime ne kadar hızlı adapte olabildiğidir. 2019 yılında "Supersonic Subatomic Java" mottosuyla yola çıkan ve derleme zamanı (build-time) metaveri işleme modeliyle JVM dünyasında soğuk başlatma (cold start) ile bellek tüketimi standartlarını yeniden yazan Quarkus, tarihinin en kapsamlı mimari dönüşümlerinden birini başlattı. 1 Ekim 2026 itibarıyla yayınlanan Quarkus 4.0.0.Beta1, iki yıllık yoğun bir mühendislik çalışmasının ürünü olarak Kasım 2026 sonunda çıkacak nihai (GA) sürümün tüm teknik temelini ortaya koyuyor.

Quarkus 4, sıradan bir sürüm yükseltmesi değildir; ağ katmanında Netty 4.2 ve Vert.x 5.x geçişinden QUIC / HTTP/3 ve io_uring yerel taşıyıcılarına, veri katmanında Hibernate ORM 8 ve Jackson 3 entegrasyonundan CDI 5.0 ve birleşik Observation API'ye kadar tüm alt sistemlerin eşzamanlı olarak yeni nesil standartlara yükseltildiği devasa bir kırılma noktasıdır.


1. Java 21 Tabanı, Sanal İş Parçacıkları ve Reaktif Çekirdek Tartışması

Quarkus 4.0.0.Beta1 ile birlikte gelen ilk ve en keskin kural, Java 17 desteğinin tamamen sonlandırılmasıdır. Çatı artık minimum çalışma zamanı olarak Java 21'i zorunlu kılmakta, üretim ortamları içinse Java 25 kullanımını önermektedir (GraalVM yerel derlemelerinde ise Mandrel 25 taban alınmaktadır).

Bu kararın arkasındaki temel mimari motivasyon, Project Loom ile gelen Sanal İş Parçacıklarını (Virtual Threads) opsiyonel bir eklenti olmaktan çıkarıp yürütme modelinin merkezine yerleştirmektir. Ancak burada Java ekosisteminde derin bir mimari tartışma da gün yüzüne çıkmaktadır: Helidon 4 gibi çatılar JDK 21 sonrasında Netty'yi tamamen terk edip %100 sanal iş parçacığı tabanlı bloklayan soket (blocking I/O) mimarisine geçerken, Quarkus 4 neden Netty 4.2 ve Vert.x 5.x reaktif omurgasını korumuştur?

"Mimari Not: Sanal iş parçacıkları, uygulama kodundaki eşzamanlılık karmaşıklığını çözer ancak dış G/Ç (I/O) bant genişliği limitlerini veya işletim sistemi çekirdeğindeki paket işleme maliyetlerini tek başına ortadan kaldırmaz. Quarkus 4, reaktif olay döngüsü (event-loop) motorunu koruyarak hem sıfır-kopya (zero-copy) ağ tamponlamasını ve çoklu protokol (QUIC, HTTP/3, gRPC) esnekliğini elinde tutmakta hem de uygulama katmanında @RunOnVirtualThread ile sanal iş parçacığı ergonomisini kayıpsız sunmaktadır."

Böylece Quarkus 4, mesajlaşma sistemleri ve yüksek frekanslı akış (streaming) senaryolarında salt reaktif boru hatlarının deterministik performansını korurken, geleneksel CRUD ve servis orkestrasyonu katmanlarında geliştiriciyi reaktif zincir (reactive chain) yazma zorunluluğundan kurtaran hibrit bir yürütme motoru (execution engine) sunmaktadır.


2. Ağ Katmanında Devrim: Vert.x 5, QUIC, HTTP/3 ve Yerel io_uring Taşıyıcıları

Quarkus 4.0.0.Beta1'in mühendislik açısından en heyecan verici yenilikleri ağ (networking) katmanında toplanmıştır. Netty 4.2 ve Vert.x 5.x yükseltmesiyle birlikte dağıtık sistemlerin yeni iletişim standardı olan QUIC protokolü çekirdek düzeye indirilmiştir.

QUIC ve HTTP/3 Entegrasyonu

TCP protokolünün doğası gereği sahip olduğu "Head-of-Line (HoL) Blocking" (tek bir kayıp paketin tüm bağlantıyı duraksatması) ve çok aşamalı TLS el sıkışma (handshake) gecikmeleri, mikroservisler arası iletişimde ve sınır (edge) ağ geçitlerinde ciddi bir darboğazdır. UDP üzerinde çalışan QUIC protokolü; bağlantı çoğullamayı (multiplexing), sıfır-RTT (0-RTT) bağlantı kurulumunu ve şifrelemeyi taşıma katmanında birleştirir.

Quarkus 4, QUIC temelini kullanarak:

  • HTTP/3 (geliştirme ve test modlarında otomatik TLS sertifikası üretimiyle birlikte opt-in olarak),
  • MQTT over QUIC (IoT ve telemetri akışları için),
  • WebTransport (QUIC üzerinde çalışan yeni nesil çift yönlü WebSocket alternatifi)

protokollerini doğrudan desteklemektedir.

Çekirdek Düzeyinde epoll ve io_uring Desteği

Standart Java NIO soketleri soyutlama katmanı nedeniyle yüksek eşzamanlılık altında sistem çağrısı (syscall) ve bağlam değiştirme (context-switch) maliyetleri üretir. Quarkus 4, Netty 4.2'nin sunduğu yerel taşıyıcıları (native transports) birinci sınıf yapılandırma seçeneği haline getirmiştir. Linux ortamlarında epoll ve özellikle asenkron halka tampon (ring buffer) mimarisiyle çekirdek-kullanıcı alanı (kernel-user space) kopyalamalarını minimize eden io_uring desteği, hem standart JVM modunda hem de GraalVM/Mandrel ile derlenen native executable (yerel ikili) imajlarda sorunsuz çalışmaktadır.

Mimari Katman / Özellik Quarkus 3.x Serisi Quarkus 4.0.0.Beta1 Mimari Etki ve Kazanım
Taban Java Sürümü Java 17 Java 21 (Önerilen: Java 25) Sanal iş parçacıklarının merkezileşmesi ve modern JVM optimizasyonları
Ağ Omurgası Netty 4.1 & Vert.x 4.x Netty 4.2 & Vert.x 5.x Yenilenmiş olay döngüsü, QUIC, HTTP/3 ve WebTransport desteği
Çekirdek G/Ç (I/O) NIO / Sınırlı epoll Yerel epoll ve io_uring (JVM + Native) Düşük kuyruk gecikmesi (tail latency) ve yüksek eşzamanlı paket işleme
Veri ve Kalıcılık Hibernate ORM 6 / 7 Hibernate ORM 8 (Persistence 4.0 & Data 1.1) Tip güvenli Jakarta Data depoları ve derleme zamanı diyalekt optimizasyonu
JSON Serileştirme Jackson 2.x Jackson 3.x Yeni paket isim alanı, katı ayrıştırma (strict parsing) ve modern API
Bağımlılık Enjeksiyonu CDI 4.x CDI 5.0 (@Eager, @Reserve) Standartlaştırılmış erken başlatma ve yedek bean çözümleme mekanizması
Gözlemlenebilirlik Ayrı Micrometer / OTel API'leri Birleşik Observation API (@Observed) Tek anotasyonla hem metrik hem dağıtık iz (trace) üretimi ve yeni Dev UI paneli

3. Gözlemlenebilirlik, CDI 5.0 ve Kafka'da @ExactlyOnce Semantiği

Üretim ortamlarındaki mikroservislerde en sık karşılaşılan kod kirliliklerinden biri, metrik toplama (Micrometer) ve dağıtık izleme (OpenTelemetry) için ayrı ayrı kesişen ilgilerin (cross-cutting concerns) ve anotasyonların yazılmasıdır. Quarkus 4.0.0.Beta1, Observation API ile bu iki dünyayı tek bir soyutlama altında birleştirir.

Geliştiriciler artık ister programatik API üzerinden isterse tek bir @Observed anotasyonu ile metotlarını işaretleyerek hem Micrometer metriklerinin hem de OpenTelemetry span/trace verilerinin eşzamanlı üretilmesini sağlayabilir. Üstelik geliştirme aşamasında (dev mode) hiçbir ek yapılandırma gerektirmeyen yerleşik Dev UI Observability Dashboard sayesinde, üretilen telemetri verileri gerçek zamanlı olarak yerel arayüzden izlenebilmektedir.

Aynı zamanda Jakarta EE 11 sonrası standartlarla hizalanan çatı, CDI 5.0 entegrasyonuyla iki önemli anotasyonu kullanıma sunar:

  • @Eager: Quarkus'a özgü @Startup yaklaşımını standart CDI seviyesine taşıyarak uygulama ayağa kalkarken ilgili bean'in derhal başlatılmasını garanti eder.
  • @Reserve: Varsayılan uygulama bileşenlerinin devreye giremediği veya özelleştirildiği senaryolarda alternatif/yedek bean önceliklendirmesini standartlaştırır.

Olay güdümlü (event-driven) mimariler tarafında ise Apache Kafka entegrasyonu @ExactlyOnce anotasyonu ile güçlendirilmiştir. Kafka'da "tüket-işle-üret" (consume-process-produce) döngülerinde geleneksel olarak karmaşık üretici/tüketici işlem (transaction) yönetimi gerektiren "tam olarak bir kez işleme" garantisi, artık deklaratif bir anotasyonla yönetilebilmektedir. Ayrıca Spring JMS, havuzlanmış (pooled) JMS ve IronJacamar uyumluluğu sunan yepyeni bir JMS uzantısı da ekosisteme eklenmiştir.

java
package com.tastutanlabs.telemetry;

import io.quarkus.observation.Observed;
import io.smallrye.common.annotation.RunOnVirtualThread;
import jakarta.enterprise.context.ApplicationScoped;
import jakarta.enterprise.inject.Eager;
import jakarta.ws.rs.Consumes;
import jakarta.ws.rs.PATCH;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.PathParam;
import jakarta.ws.rs.Produces;
import jakarta.ws.rs.core.MediaType;
import org.eclipse.microprofile.reactive.messaging.Incoming;
import org.eclipse.microprofile.reactive.messaging.Outgoing;
import io.smallrye.reactive.messaging.kafka.transactions.ExactlyOnce;

@Eager // CDI 5.0: Uygulama başlangıcında bean'i hazırla
@ApplicationScoped
@Path("/api/v1/devices")
public class TelemetryGatewayResource {

    // Jakarta REST 4.0: Standart RFC 7396 JSON Merge Patch desteği
    @PATCH
    @Path("/{deviceId}/config")
    @Consumes("application/merge-patch+json")
    @Produces(MediaType.APPLICATION_JSON)
    @Observed(name = "device.config.patch", contextualName = "patch-device-config")
    @RunOnVirtualThread // Java 21+ Sanal İş Parçacığı üzerinde bloklamadan çalıştır
    public DeviceConfig updatePartialConfig(@PathParam("deviceId") String deviceId, DeviceConfigPatch patch) {
        // Tek @Observed anotasyonu ile hem Micrometer metriği hem OpenTelemetry trace üretilir
        return DeviceRegistry.applyMergePatch(deviceId, patch);
    }

    // Quarkus 4 Kafka: Deklaratif @ExactlyOnce işlem garantisi
    @Incoming("raw-sensor-events")
    @Outgoing("validated-sensor-events")
    @ExactlyOnce
    @Observed(name = "sensor.stream.process")
    public ValidatedEvent processSensorStream(RawSensorEvent event) {
        return new ValidatedEvent(event.deviceId(), event.payload(), System.currentTimeMillis());
    }

    public record DeviceConfigPatch(Integer samplingRateHz, Boolean enableQuicTransport) {}
    public record DeviceConfig(String id, int samplingRateHz, boolean enableQuicTransport) {}
    public record RawSensorEvent(String deviceId, String payload) {}
    public record ValidatedEvent(String deviceId, String payload, long processedAt) {}
}

Yukarıdaki kod örneğinde görüldüğü üzere, Jakarta REST 4.0 ile gelen yerel JSON Merge Patch (application/merge-patch+json) desteği sayesinde kısmi kaynak güncellemeleri için özel serileştirici yazma ihtiyacı da ortadan kalkmıştır.


4. Veri Katmanı ve Kırılma Noktaları: Hibernate ORM 8 ve Jackson 3 Göçü

Quarkus 4.0.0.Beta1'i üretim ortamlarına taşımayı planlayan mühendislik ekipleri için en kritik mesai, veri erişim ve JSON serileştirme katmanlarındaki büyük sürüm geçişlerinde harcanacaktır.

Hibernate ORM 8, Jakarta Persistence 4.0 ve Jakarta Data 1.1

Quarkus 4, veri katmanını doğrudan Hibernate ORM 8 sürümüne yükseltmiştir. Bu yükseltme, Jakarta Persistence 4.0 ve derleme zamanında tip güvenli sorgu doğrulaması yapan Jakarta Data 1.1 spesifikasyonlarını beraberinde getirir.

Ancak göç kılavuzunda (Migration Guide) altı çizilen çok önemli bir mimari detay bulunmaktadır: Quarkus 4, derleme zamanında (build-time) Hibernate yapılandırmasını oluştururken artık çok daha güncel veritabanı sürümlerini varsayılan olarak kabul etmektedir. Eğer uygulama üretim ortamında eski bir ilişkisel veritabanı sürümüne bağlanıyorsa, üretilen SQL diyalekti uyuşmazlığı nedeniyle uygulama başlangıçta hata verebilir. Ekiplerin ya veritabanı motorlarını güncellemeleri ya da application.properties üzerinden hedef veritabanı sürümünü açıkça tanımlamaları gerekmektedir.

Jackson 3: Anotasyonlar Hariç Her Şey Değişti

Belki de ekosistemdeki en sarsıcı değişiklik Jackson 2'den Jackson 3'e yapılan geçiştir. Jackson 3, geriye dönük uyumluluk yüklerinden kurtulmak amacıyla çekirdek (core) ve veri bağlama (databind) sınıflarının paket isim alanlarını (namespace) tamamen değiştirmiştir. Yalnızca com.fasterxml.jackson.annotation paketindeki anotasyonlar mevcut isim alanını korumaktadır; bunun dışındaki tüm programatik ObjectMapper ve özel serileştirici (custom serializer/deserializer) importlarının güncellenmesi gerekmektedir.

"Mimari Not: Jackson 3 yalnızca paket isimlerini değiştirmekle kalmaz, aynı zamanda varsayılan ayrıştırma (parsing) davranışını çok daha katı hale getirir. Artık serileştirilen bir JSON değerinden sonra gelen fazladan karakterler (trailing tokens) ve ilkel (primitive) tipler için gönderilen null değerler varsayılan olarak reddedilmektedir. Geriye dönük API sözleşmelerinde esneklik arayan sistemlerin bu davranışları yapılandırma üzerinden açıkça esnetmesi şarttır."

properties
# ===================================================================
# Quarkus 4.0.0.Beta1 - Ağ, Taşıyıcı ve Uyumluluk Yapılandırması
# ===================================================================

# 1. HTTP/3 ve QUIC Desteğini Aktifleştirme (Dev/Test modunda otomatik sertifika üretir)
quarkus.http.http3.enabled=true

# 2. Linux Çekirdeği Düzeyinde Yerel io_uring Taşıyıcısını Kullanma (JVM ve Native)
quarkus.vertx.prefer-native-transport=true
quarkus.vertx.transport=io_uring

# 3. Hibernate ORM 8: Eski Veritabanı Motorları İçin Açık Sürüm Bildirimi
quarkus.datasource.db-kind=postgresql
quarkus.datasource.db-version=15.0

# 4. OpenTelemetry: Yeni Semantik Konvansiyonlar ve Birleşik Gözlemlenebilirlik
quarkus.otel.traces.enabled=true
quarkus.micrometer.enabled=true

Ayrıca OpenTelemetry uzantısı da en güncel semantik konvansiyonlarla (semantic conventions) hizalanmıştır. Örneğin gRPC ve RPC izlemelerinde kullanılan rpc.system özniteliği, yeni standart doğrultusunda rpc.system.name olarak yeniden adlandırılmıştır; bu durum mevcut Grafana veya Prometheus sorgularının güncellenmesini gerektirir.


5. Mühendislik Ekipleri İçin Stratejik Çıkarımlar

Kasım 2026 sonunda Genel Kullanıma (GA) açılması ve Mart 2027'de ilk LTS sürümüne kavuşması planlanan Quarkus 4 treni, kurumsal Java mimarileri için net bir yol haritası çizmektedir:

  1. Java 17 Teknik Borçtur: Java 21 tabanının zorunlu hale gelmesi ve Java 25'in önerilmesi, hala JDK 17 üzerinde çalışan mikroservis kümeleri için yükseltme sürecinin artık ertelenemeyeceğini göstermektedir.
  2. İç Ağlarda ve Sınırda (Edge) QUIC Dönemi: io_uring yerel taşıyıcıları ile birleşen HTTP/3 ve WebTransport desteği, yüksek paket kaybı yaşanan mobil/IoT ağlarında veya yoğun servis-arası (east-west) trafikte C++/Rust tabanlı vekil sunuculara duyulan ihtiyacı azaltarak doğrudan Java katmanında ultra düşük gecikmeli iletişim kurulmasına olanak tanımaktadır.
  3. Erken Uyumluluk Testleri: Jackson 3 paket değişiklikleri, Hibernate ORM 8 veritabanı diyalekt kontrolleri ve Vert.x 5 API geçişleri nedeniyle özel Quarkus uzantısı (extension) geliştiren veya derin programatik entegrasyonlar kullanan ekiplerin, io.quarkus.platform:quarkus-bom:4.0.0.Beta1 üzerinden derleme ve entegrasyon testlerine bugünden başlaması kritik bir mühendislik refleksidir.
Konu Etiketleri
#Quarkus 4#Java 21#Vert.x 5#HTTP/3#io_uring#Hibernate ORM 8#Jackson 3#Bulut Yerli Mimari
Emre Taştutan
Emre TaştutanGeliştirici & AI Meraklısı

Yazılım mimarisi, mikroservis ekosistemleri ve üretken yapay zeka uygulamaları üzerine çalışıyorum. TastutanLabs çatısı altında geliştirici araçları ve SaaS ürünleri inşa ediyorum.

@tastutanlabs • Instagram Mini-Blog

Bu analizin 6 kartlık görsel özetini Instagram'da inceleyin ve kaydedin

Her gün yazılım mimarisi, Java/JVM ve yapay zeka gelişmelerini kendi başına okunabilen 6 slaytlık Mini-Blog serileri halinde paylaşıyoruz.

Instagram'da Takip Et →
Bu Yazıyı Paylaş:

Yorumlar (0)

Düşüncelerinizi Paylaşın

Henüz yorum yapılmamış. İlk yorumu siz yapın!

Bu Kategorideki Diğer İncelemeler

Yapay Zeka & Gelecek

3D Silikon Küplerden 60 Milyar Dolarlık TPU Borçlanmasına: Mueon Cubelet, Anthropic "Project North Star", Katı Eşikli Güvenlik Yasası ve GB200 NVL72 Değer Zinciri Anatomisi

Eski Intel mühendislerinin kurduğu Mueon'un 65 milyon dolarlık 3D "Cubelet" sunucu mimarisi, Anthropic'in 1.5 GW TPU kapasitesi için Blackstone'a sunduğu %10+ getirili 60 milyar dolarlık borç paketi, Kongre'ye sunulan 1 milyar dolar hasar eşikli güvenlik yasası ve UNCTAD'ın NVIDIA GB200 NVL72 üzerinden ortaya koyduğu küresel katma değer asimetrisi mercek altında.

Emre TaştutanEmre Taştutan
12 dk
Yapay Zeka & Gelecek

Silikon Üçgeni ve Bellek Duvarı: NVIDIA Blackwell/Rubin, Apple M5 Unified Memory ve Google TPU v7 Ironwood’un Mimari Çarpışması

Büyük Dil Modellerinde (LLM) darboğaz artık FLOPS değil, elektronların silikon üzerindeki hareket maliyetidir. NVIDIA'nın HBM3e/HBM4 tabanlı kaba kuvveti, Apple M5 Ultra'nın 512 GB'lık Sıfır-Kopya (Zero-Copy) Birleşik Belleği ve Google TPU v7 Ironwood'un 9.216 çipli 3D Torus Sistolik Dizileri arasındaki mimari savaşı, Roofline modeli ve çekirdek seviyesi kodlarla inceliyoruz.

Emre TaştutanEmre Taştutan
17 dk