DEV Community: Titouan Despierres

Scaling Java 26 AI Workloads: A 2026 Production Playbook (GitOps & Kubernetes)

Titouan Despierres — Thu, 26 Feb 2026 10:58:03 +0000

Scaling Java 26 AI Workloads: A 2026 Production Playbook (GitOps & Kubernetes)

The landscape of enterprise development in early 2026 is defined by a singular challenge: moving beyond AI experimentation into reliable, high-scale production operations. With the arrival of JDK 26-RC1, the promise of Project Loom (Virtual Threads) and Project Panama (Foreign Function & Memory API) has matured into the backbone of high-performance AI integration in the Java ecosystem.

This article provides a practical blueprint for architecting, building, and deploying Java 26 AI services on Kubernetes using a modern GitOps flow with GitHub Actions, GitLab CI, and Argo CD.

1. The Java 26 Advantage: Why JDK 26 for AI?

JDK 26 brings significant refinements that directly impact how we handle AI inference and data processing.

Project Panama: Native Model Interaction

The Foreign Function & Memory API (JEP 472) is no longer "new"—it is the standard. In 2026, we use it to interface directly with C++ AI libraries (like llama.cpp or custom CUDA kernels) without the overhead of JNI.

Performance: Reduced latency when passing large tensors between Java and native memory.
Safety: Deterministic memory management for off-heap AI model weights.

Virtual Threads (Loom) at Scale

For I/O-bound AI services (calling external LLM APIs like OpenAI, Anthropic, or internal vLLM clusters), Virtual Threads allow us to handle thousands of concurrent requests with a tiny footprint.

2. The Build Pipeline: Containerizing JDK 26

A production-grade pipeline must focus on security and size. We use multi-stage Docker builds with jlink to strip down the JDK to only the required modules.

Modern GitHub Actions Workflow

name: Build and Push Java AI Service
on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up JDK 26
        uses: actions/setup-java@v4
        with:
          java-version: '26-ea'
          distribution: 'temurin'
          cache: 'maven'

      - name: Build with Maven
        run: mvn clean package -DskipTests

      - name: Create Custom JRE via jlink
        run: |
          $JAVA_HOME/bin/jlink \
            --add-modules java.base,java.net.http,jdk.management \
            --strip-debug \
            --no-man-pages \
            --no-header-files \
            --compress=2 \
            --output custom-jre

      - name: Build & Push Image
        run: |
          docker build -t registry.example.com/ai-service:${{ github.sha }} .
          docker push registry.example.com/ai-service:${{ github.sha }}

3. The GitLab CI Parallel: Enterprise Readiness

If you are on GitLab, leverage Environment Stop and Security Scanning as first-class citizens.

stages:
  - test
  - build
  - security
  - deploy

container_scanning:
  stage: security
  image:
    name: aquasec/trivy:latest
  script:
    - trivy image --severity HIGH,CRITICAL registry.example.com/ai-service:$CI_COMMIT_SHA

4. Kubernetes & GitOps: The Argo CD Pattern

In 2026, manual kubectl apply is a relic of the past. We use Argo CD for declarative, versioned deployments.

The Kustomize Overlay

AI workloads often require specific GPU resources. Use Kustomize to inject resource limits only for production.

# overlays/production/resources-patch.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: java-ai-service
spec:
  template:
    spec:
      containers:
      - name: app
        resources:
          limits:
            nvidia.com/gpu: 1
            memory: "8Gi"
          requests:
            cpu: "2"
            memory: "4Gi"

The Argo CD Application manifest

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: java-ai-service-prod
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/gitops-config.git
    targetRevision: HEAD
    path: apps/java-ai-service/overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: ai-production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

5. Observability & Rollout Strategies

AI services are prone to model drift and latency spikes. Implementing a Canary Rollout with Argo Rollouts is essential.

Why Canary?

Safety: Traffic is shifted incrementally (10% -> 20% -> 50% -> 100%).
Verification: If LLM response latency exceeds 500ms or error rates climb, the system triggers an automatic rollback.

# rollout.yaml (Argo Rollouts)
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: java-ai-service
spec:
  strategy:
    canary:
      steps:
      - setWeight: 10
      - pause: { duration: 5m }
      - setWeight: 50
      - pause: { duration: 10m }

6. Adoption Strategy: How to Start

Audit your JDK version: If you are still on JDK 17, skip 21 and target JDK 25 (LTS) or 26 (Latest) to leverage Panama.
Move to GitOps: Stop using CI pipelines to "push" to K8s. Use them to update a GitOps repo that Argo CD "pulls" from.
Isolate AI Logic: Keep your "Orchestration" (Java) separate from your "Inference" (C++/Python/CUDA) using Panama or gRPC for maximum stability.

Conclusion

Java's role in the AI era is not as the model-training language, but as the reliable platform engineering language. By combining JDK 26's native efficiencies with Kubernetes-native GitOps, we build systems that are not just smart, but production-hardened.

Tags: #java #kubernetes #ai #devops

Optimizing Java AI Architectures for 2026: JDK 26, HTTP/3, and GitOps Control Planes

Titouan Despierres — Tue, 24 Feb 2026 14:53:25 +0000

Optimizing Java AI Architectures for 2026: JDK 26, HTTP/3, and GitOps Control Planes

As we move into early 2026, the intersection of Java, Cloud Native, and AI is undergoing a massive shift. With JDK 26 entering its Final Release Candidate (RC) phase and the stabilization of HTTP/3 within the Java ecosystem, the way we build, deploy, and observe high-performance AI-driven services has fundamentally changed.

In this guide, we’ll explore how to leverage the latest Java capabilities alongside modern DevOps patterns (GitLab/GitHub, Argo CD, and Kubernetes) to build a production-grade AI inference gateway.

1. The Java Platform Shift: JDK 26 and HTTP/3

JDK 26 is not just another incremental update. Two key JEPs are changing the game for AI and high-frequency workloads:

JEP 517: HTTP/3 for the HTTP Client API

In AI architectures, low latency is everything. HTTP/3 (QUIC) solves the head-of-line blocking issues common in HTTP/2. For an AI Gateway that orchestrates calls between multiple LLM providers (OpenAI, Anthropic, or local Ollama instances), this means a more resilient and faster connection.

JEP 516: Ahead-of-Time (AOT) Object Caching

This allows the JVM to "warm up" object graphs before execution. For AI applications using heavy frameworks like LangChain4j or Spring AI, reducing the cold-start latency of your Kubernetes pods is a significant win.

2. CI/CD for AI Services: Unified Pipelines

Whether you are on GitLab or GitHub, your pipeline needs to handle more than just a mvn package. You need deep integration with your Kubernetes observability stack.

Example: GitHub Actions for Java AI Deployment

Here is a modernized workflow that uses GitHub Actions to build a JDK 26 container and notify Argo CD via GitOps.

name: Deploy Java AI Gateway

on:
  push:
    branches: [ "main" ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up JDK 26
        uses: actions/setup-java@v4
        with:
          java-version: '26'
          distribution: 'temurin'

      - name: Build with Maven
        run: mvn clean package -DskipTests

      - name: Build and Push Docker Image
        run: |
          docker build -t my-org/ai-gateway:${{ github.sha }} .
          docker push my-org/ai-gateway:${{ github.sha }}

  gitops-update:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Update Kustomize Manifest
        run: |
          git clone https://github.com/my-org/gitops-infra.git
          cd gitops-infra/apps/ai-gateway
          kustomize edit set image ai-gateway=my-org/ai-gateway:${{ github.sha }}
          git config user.name "GitOps Bot"
          git config user.email "bot@my-org.com"
          git commit -am "chore: update ai-gateway image to ${{ github.sha }}"
          git push

3. Kubernetes & GitOps: The Argo CD Pattern

Manual kubectl apply is a relic of the past. In 2026, Argo CD is the standard for ensuring your cluster state matches your repository.

Practical Argo CD Application Manifest

To ensure high availability and observability, your Argo CD Application should reference a structured Helm or Kustomize layout:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: ai-gateway-prod
  namespace: argocd
spec:
  project: default
  source:
    repoURL: 'https://github.com/my-org/gitops-infra.git'
    targetRevision: HEAD
    path: apps/ai-gateway/overlays/prod
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: ai-apps
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

4. Production Observability: The Feedback Loop

Deploying is only half the battle. For AI services, you must monitor TTFT (Time To First Token) and Inference Latency.

Using Kubernetes Horizontal Pod Autoscaler (HPA) based on custom metrics (like active HTTP/3 streams) is essential.

K8s Manifest for Advanced Scaling

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: ai-gateway-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: ai-gateway
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

5. Summary & Adoption Strategy

To adopt these patterns in your organization:

Test JDK 26 RC: Use it for non-critical internal tools to benchmark JEP 517 (HTTP/3) benefits.
Standardize GitOps: Move your CI/CD pipelines to a push-to-git model instead of direct cluster access.
Observability First: Don't ship AI features without tracing (OpenTelemetry is your friend here).

JDK 26 provides the performance, and GitOps provides the control. Combined, they form the bedrock of reliable AI systems in 2026.

What’s your experience with Java and AI in production? Let's discuss in the comments!

java #kubernetes #devops #ai

Optimizing Java AI Workloads on Kubernetes: A 2026 GitOps Playbook

Titouan Despierres — Tue, 24 Feb 2026 14:50:55 +0000

Optimizing Java AI Workloads on Kubernetes: A 2026 GitOps Playbook

As we move further into 2026, the intersection of Java 25, Agentic AI, and Cloud Native infrastructure has matured into a robust ecosystem. For DevOps and Platform Engineers, the challenge is no longer just "getting it to run," but optimizing for inference performance, cost-efficiency, and secure delivery via modern CI/CD patterns.

In this guide, we’ll explore how to architect a production-grade pipeline for a Java-based AI service using GitHub Actions, GitLab CI, and GitOps with Argo CD on Kubernetes.

1. The Java 25 Edge: Native Memory & AI Frameworks

With the recent JEPs in Java 25 (Project Loom and Panama refinements), Java has become a formidable platform for AI inference. The key is managing Off-Heap memory correctly for large language models or vector embeddings.

Practical Pattern: Resource Management in K8s

When running a Spring AI or LangChain4j application, your JVM memory footprint is split. You must account for the MaxDirectMemorySize when setting your Kubernetes limits.

# Kubernetes Deployment Snippet
spec:
  containers:
  - name: java-ai-service
    image: acme/java-ai-app:latest
    resources:
      requests:
        memory: "2Gi"
        cpu: "1000m"
      limits:
        memory: "4Gi" # Leave headroom for Native Memory
    env:
    - name: JAVA_OPTS
      value: "-XX:MaxRAMPercentage=75.0 -XX:MaxDirectMemorySize=1G"

2. CI/CD: The Dual-Platform Strategy

Whether you are on GitLab or GitHub, your pipeline should focus on OCI compliance and automated vulnerability scanning.

GitHub Actions: Agentic Workflow Integration

GitHub's 2026 updates introduced enhanced agentic workflows. Here is a modern release.yml for a Java AI project:

name: Build and Push
on:
  push:
    tags: ['v*']

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up JDK 25
        uses: actions/setup-java@v4
        with:
          java-version: '25'
          distribution: 'temurin'
      - name: Build with Maven
        run: mvn clean package -DskipTests
      - name: Build and Push OCI Image
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: user/java-ai:latest

GitLab CI: Multi-Project Pipelines for Platform Engineering

In GitLab, the "Platform Engineering" approach uses shared templates to enforce security.

# .gitlab-ci.yml
include:
  - project: 'platform/templates'
    file: '/java/default-pipeline.yml'

variables:
  DOCKER_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG

stages:
  - build
  - test
  - deploy-preview

deploy:preview:
  stage: deploy-preview
  script:
    - kustomize edit set image app=$DOCKER_IMAGE
    - git commit -am "chore:update preview image"
    - git push origin HEAD

3. GitOps with Argo CD: The Progressive Rollout

Continuous Deployment isn't enough; you need Observability-driven rollouts. Argo CD Rollouts allow us to perform Canary deployments for our AI services.

Argo CD Rollout Manifest

Instead of a standard Deployment, use a Rollout:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: ai-inference-engine
spec:
  replicas: 5
  strategy:
    canary:
      steps:
      - setWeight: 20
      - pause: {duration: 10m}
      - setWeight: 50
      - pause: {duration: 5m}
  template:
    # ... standard pod template

4. Production Strategy: Observability & Rollback

For AI workloads, traditional HTTP health checks are insufficient. You need to monitor Inference Latency and Token Usage.

Key recommendations:

Security: Use Chainguard or Wolfi-based "distroless" images to reduce the attack surface of your Java containers.
Rollback: Always keep your GitOps repository as the "Source of Truth". If a model performs poorly in production (hallucinations or latency spikes), a simple git revert on your Argo CD repo is your safest rollback mechanism.
Adoption: Start with Internal Developer Portals (IDP) like Backstage to template these complex AI + K8s manifests for your developers.

Conclusion

Java's renaissance in the AI era is driven by its stability and the power of Kubernetes. By leveraging GitHub Actions for rapid CI, GitLab for enterprise governance, and Argo CD for GitOps, you create a resilient platform ready for the scale of 2026.

What is your current bottleneck in Java AI deployments? Let's discuss in the comments!

java #kubernetes #devops #ai

Shipping Java AI Services on Kubernetes in 2026: A Practical CI/CD Playbook (GitHub Actions + GitLab CI + Argo CD)

Titouan Despierres — Sun, 22 Feb 2026 13:25:34 +0000

Shipping Java AI Services on Kubernetes in 2026: A Practical CI/CD Playbook (GitHub Actions + GitLab CI + Argo CD)

If you build production systems with Java and Kubernetes, 2026 feels different from even two years ago.

The stack is more capable, but also less forgiving:

Java moved forward fast (JDK 21 in production, JDK 25 now on the adoption table)
AI features are no longer “labs-only” and now sit in real SLAs
Kubernetes keeps evolving APIs and operational defaults
CI/CD shifted from “just run tests” to provenance, policy, and progressive delivery

This article is a field playbook: what changed, why it’s better (or what trade-offs you pay), and how to adopt safely in production.

1) Java in 2026: LTS strategy is now an architecture decision

Many teams are on Java 17 or 21. The strategic question now is not if you move, but how often you want to absorb JVM/runtime changes.

What changed

JDK 21 proved itself in production (virtual threads adoption matured, better startup/perf ergonomics).
JDK 25 (LTS) is now the next serious target for teams wanting fresh runtime optimizations and longer runway.
Teams increasingly separate:
- language/runtime cadence (JDK upgrades)
- framework cadence (Spring, Micronaut, Quarkus)

Why it’s better

Better throughput-per-core and latency consistency on modern workloads.
Easier concurrency scaling with virtual threads for I/O-heavy services.
Cleaner migration planning when platform teams enforce one baseline JDK per environment.

Trade-offs

JDK upgrades surface hidden assumptions (reflection, unsafe libs, GC tuning folklore).
Preview/incubator features are tempting but can create policy debates in regulated environments.

Adoption strategy (production-safe)

Move from “lift-and-pray” to benchmark-driven migration.
Enforce runtime parity between CI and cluster images.
Make rollback trivial: immutable image tags + GitOps revision pin.

Useful baseline command set:

# JVM + GC shape under realistic load
java -Xlog:gc*:stdout:time -jar app.jar

# JDK migration smoke check
jdeps --multi-release 21 --recursive app.jar

2) AI in production: model choice became a platform concern, not an app concern

In many companies, AI features now sit inside Java APIs (classification, extraction, assistant workflows, anomaly triage). The biggest shift is operational: model routing, fallback, and cost controls are now platform-level primitives.

What changed

Teams run multi-model strategies (fast/small + accurate/expensive fallback).
Inference is increasingly exposed behind internal gateways with quotas and observability.
“Prompt quality” alone is no longer enough; SLOs and budget guardrails decide architecture.

Why it’s better

Better cost/performance by matching model size to request class.
Easier governance (PII handling, rate limits, auditability) when centralized.
Faster iteration when app teams consume a stable internal AI contract.

Trade-offs

More infra complexity (gateways, retries, circuit breakers, prompt/version tracing).
Evaluation debt: you need regression datasets, not just anecdotal testing.

Practical Java pattern

Keep application code model-agnostic:

public interface AiClient {
    AiResult infer(AiRequest request);
}

Then route by policy (latency tier, tenant, budget) outside business logic.

And for reliability, treat AI calls like any other remote dependency:

timeout budgets
bulkheads
fallback behavior
semantic caching where safe

3) Kubernetes: API drift and operations policy are now daily reality

Kubernetes evolution is steady, and the operational impact is cumulative. Teams that delay upgrades too long pay the “API cliff” tax later.

What changed

Deprecated APIs keep disappearing across releases.
Security defaults and admission controls are tighter in modern clusters.
Progressive delivery expectations grew: canary/blue-green is becoming standard for critical services.

Why it’s better

Better security posture by default.
Fewer ambiguous deployment states.
Better resilience when rollout policy is encoded instead of tribal.

Trade-offs

Manifest maintenance is continuous work, not one-off.
Platform teams must own upgrade rehearsal and compatibility scanning.

Adoption strategy

Run a scheduled API deprecation scan in CI.
Keep app manifests simple; push complexity to platform-level templates.
Normalize probes/resources/securityContext defaults.

Example deployment baseline:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders-api
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  template:
    spec:
      securityContext:
        runAsNonRoot: true
      containers:
        - name: app
          image: ghcr.io/acme/orders-api:1.12.0
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet: { path: /actuator/health/readiness, port: 8080 }
          livenessProbe:
            httpGet: { path: /actuator/health/liveness, port: 8080 }
          resources:
            requests: { cpu: "250m", memory: "512Mi" }
            limits: { cpu: "1000m", memory: "1Gi" }

4) CI/CD in 2026: from pipeline automation to delivery governance

The old target was “green pipeline.” The new target is “trusted, reversible delivery.”

That means three things:

Build provenance/security signals
Progressive deploy policy
Fast rollback path

GitHub Actions example (build + scan + push)

name: build-and-push
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write
      packages: write
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: '25'
      - name: Build
        run: ./gradlew clean test bootJar
      - name: Build image
        run: |
          docker build -t ghcr.io/acme/orders-api:${{ github.sha }} .
          docker push ghcr.io/acme/orders-api:${{ github.sha }}

GitLab CI example (test + image + manifest update)

stages: [test, build, deploy]

variables:
  IMAGE: registry.gitlab.com/acme/orders-api:$CI_COMMIT_SHA

test:
  stage: test
  image: eclipse-temurin:25
  script:
    - ./gradlew test

build_image:
  stage: build
  image: docker:27
  services: [docker:27-dind]
  script:
    - docker build -t $IMAGE .
    - docker push $IMAGE

deploy_gitops:
  stage: deploy
  image: alpine:3.20
  script:
    - apk add --no-cache git yq
    - git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com/acme/platform-config.git
    - cd platform-config/apps/orders-api/overlays/prod
    - yq -i '.images[0].newTag = env(CI_COMMIT_SHA)' kustomization.yaml
    - git config user.email "ci@acme.com"
    - git config user.name "gitlab-ci"
    - git commit -am "orders-api: $CI_COMMIT_SHA"
    - git push

This is the key shift: application repo builds artifacts; config repo controls runtime state.

5) GitOps with Argo CD: make rollback boring

Argo CD works best when teams optimize for predictability, not cleverness.

Core production pattern

One app, one clear source of truth path
Environment overlays (dev/stage/prod) via Helm or Kustomize
Sync policies explicit; auto-sync only where blast radius is understood

Example Argo CD Application:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: orders-api-prod
spec:
  project: prod
  source:
    repoURL: https://github.com/acme/platform-config.git
    targetRevision: main
    path: apps/orders-api/overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: orders
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Rollback strategy that actually works

Keep previous N image tags retained in registry.
Revert config commit (not kubectl patch in prod).
Measure rollback MTTR as a platform KPI.

If rollback is manual and stressful, your delivery system is unfinished.

6) A realistic 90-day adoption roadmap

If your current baseline is Java 17/21 + Kubernetes + ad-hoc CI, here is a pragmatic rollout:

Days 1–30: Stabilize the foundation

Inventory JDK/runtime versions and unsupported dependencies.
Standardize base container image and JVM flags.
Add deployment health checks and resource defaults.
Introduce config repo for at least one service.

Days 31–60: Secure and govern delivery

Add image scanning + dependency checks in CI.
Enforce branch protections and required pipeline gates.
Add Argo CD for one production service with clear rollback drill.
Define AI request classes and model routing policy.

Days 61–90: Optimize for speed and reliability

Migrate a high-traffic Java service to latest target JDK.
Add canary rollout policy for critical services.
Instrument end-to-end latency (API + model + DB) with SLO dashboards.
Track DORA + rollback MTTR + AI cost/request in one operational view.

Final take

The winning pattern in 2026 is not “adopt every new thing fast.”

It is:

Upgrade deliberately (Java + Kubernetes)
Operationalize AI (routing, reliability, cost controls)
Treat CI/CD as governance (not just automation)
Use GitOps to make rollback routine

If your team can answer, at any moment, what changed, why it changed, and how to revert safely, you are ahead of most organizations already.

That’s what mature platform engineering looks like today.

Replacing org.n52 JtsModule for Jackson 3: Introducing io.github.aytronnfr.jackson.jts.JtsModule

Titouan Despierres — Fri, 20 Feb 2026 15:59:20 +0000

Replacing `org.n52.jackson.datatype.jts.JtsModule` for Jackson 3: Introducing `io.github.aytronnfr.jackson.jts.JtsModule`

If you are migrating to Spring Boot 4 and Jackson 3, you have probably hit this problem:

your geospatial JSON stack still depends on Jackson 2-era modules,
but your app now runs on tools.jackson.*.

I hit the same wall and built a replacement module:

old: org.n52.jackson.datatype.jts.JtsModule
new: io.github.aytronnfr.jackson.jts.JtsModule

Repository: https://github.com/aytronnFR/jts-jackson3-module

TL;DR

jts-jackson3-module provides GeoJSON serialization/deserialization for JTS on Jackson 3.
It is designed for Spring Boot 4.x projects using tools.jackson.*.
It includes round-trip and compatibility tests to reduce migration risk.

Why this module exists

Spring Boot 4 moves to Jackson 3. That means many older JSON modules built around Jackson 2 package names no longer fit cleanly.

For JTS geometries, this can block migration or force ugly temporary workarounds.

This module is a drop-in migration path for teams that need:

clean support for org.locationtech.jts geometries,
GeoJSON read/write behavior,
modern build/publish workflow (GitHub Packages + Maven Central).

Compatibility targets

jts-jackson3-module is built for:

Spring Boot 4.x
Jackson 3 (tools.jackson.*)
JTS (org.locationtech.jts)

Dependency

dependencies {
  implementation("io.github.aytronnfr:jts-jackson3-module:0.1.0")
}

Basic usage

import io.github.aytronnfr.jackson.jts.JtsModule;
import tools.jackson.databind.json.JsonMapper;
import org.locationtech.jts.geom.GeometryFactory;
import org.locationtech.jts.geom.PrecisionModel;
@Configuration
public class JsonConfig {
  @Bean
  public GeometryFactory geometryFactory() {
    return new GeometryFactory(new PrecisionModel(), 4326);
  }

  public static void configJsonMapper(GeometryFactory geometryFactory, Builder builder) {
    // 1) Modules
    builder.addModule(new JtsModule(geometryFactory));
    ...
  }
}

That’s enough to start serializing/deserializing JTS geometries in a Jackson 3 stack.

Advanced usage: include bbox for selected geometry types

import io.github.aytronnfr.jackson.jts.GeometryType;
import io.github.aytronnfr.jackson.jts.IncludeBoundingBox;
import io.github.aytronnfr.jackson.jts.JtsModule;

var module = new JtsModule(IncludeBoundingBox.forTypes(GeometryType.POINT), 8);

This lets you control output precision and bounding-box behavior for targeted geometry classes.

Migration notes from `org.n52...` module

When migrating, I recommend this order:

Replace dependency with io.github.aytronnfr:jts-jackson3-module.
Register new JtsModule() in your Jackson 3 JsonMapper config.
Run contract tests against existing API payload fixtures.
Validate edge cases: precision, bbox output, null geometry handling.
Roll out with canary if geospatial payloads are customer-facing.

Testing strategy used in the project

The repo includes:

round-trip tests for Jackson 3 behavior,
compat tests against legacy org.n52.jackson:jackson-datatype-jts:2.0.0,
shared fixtures for deterministic comparisons.

That is important because geospatial JSON regressions are often subtle (ordering, precision, bbox shape) and can break downstream consumers silently.

CI/CD and publishing

The project includes GitHub Actions for:

CI on push/PR,
publish on version tags,
manual release flow.

Publishing is wired for:

GitHub Packages
Maven Central

Practical impact for Boot 4 teams

In real migrations, this removes a key blocker: staying with old module assumptions while the rest of your app has already moved to Jackson 3.

You keep your geospatial payload capability without freezing your platform upgrade.

What’s next

The roadmap I’m focusing on:

expand compatibility fixtures,
benchmark serialization overhead on larger geometry sets,
document migration recipes for common Spring Boot setups.

If you’re migrating a GIS-heavy API to Boot 4, feedback and issue reports are very welcome.

Repo: https://github.com/aytronnFR/jts-jackson3-module

Spring Boot 4.0 Migration Guide for Production Teams: What Actually Breaks and How to Upgrade Safely

Titouan Despierres — Fri, 20 Feb 2026 12:54:50 +0000

Spring Boot 4.0 Migration Guide for Production Teams: What Actually Breaks and How to Upgrade Safely

Spring Boot 4.0 is not a routine version bump. For most Java teams, it is a platform migration touching Java baseline, Jakarta alignment, dependency graph, packaging behavior, test setup, and especially JSON handling with Jackson 3.

This guide summarizes the official migration notes into a practical, production-focused playbook.

TL;DR

Upgrade to the latest 3.5.x first, remove deprecations, then move to 4.0.
The biggest migration risks are module/starter changes and Jackson 3 behavior shifts.
Use a staged rollout: stabilize with compatibility options, then converge to native Boot 4 patterns.

Why this migration is bigger than usual

Spring Boot 4.0 upgrades major foundations at once:

Java baseline: 17+ (latest LTS recommended)
Servlet baseline: 6.1
Jakarta EE: 11
Spring Framework: 7.x
Preferred JSON engine: Jackson 3

That means many apps compile but still fail at runtime (serialization contracts, missing transitive dependencies, test infra drift, startup assumptions).

Step 0: Before touching Boot 4

1) Move to latest Boot 3.5.x

Do this first so you are already on the newest dependency line and can clean warnings progressively.

2) Remove 3.x deprecations

Anything deprecated in Boot 3.x is a removal candidate in 4.0.

3) Audit external BOMs and managed libs

If you pin versions outside Boot management (for example Spring Cloud), validate Boot 4 compatibility before upgrading.

4) Re-check environment requirements

Java 17+
Kotlin 2.2+ (if used)
GraalVM 25+ for native-image

Features removed in Boot 4 you must account for

From the migration guide, notable removals include:

Undertow support dropped (Servlet 6.1 baseline incompatibility)
Pulsar reactive auto-configuration removed
Embedded launch scripts for fully executable jars removed
Spock integration removed (Groovy 5 gap)
Direct Boot support removed for Spring Session Hazelcast/MongoDB integrations

If your runtime or packaging relies on these features, plan alternatives before switching versions.

The biggest structural change: modularization

Boot 4 introduces smaller focused modules and a more consistent starter model.

What changes in practice

More technologies now have dedicated starters.
Test infra is also modularized with companion test starters.
If your app relied on implicit transitive deps, you may now miss required pieces.

Typical example

If you used Flyway/Liquibase only via third-party dependency before, Boot 4 expects explicit Boot starter usage:

spring-boot-starter-flyway
spring-boot-starter-liquibase

Test side impact

You should depend on technology-specific test starters, not just one global test starter.

For example, security test behavior now expects proper security test starter alignment.

Transition path: classic starters

For teams upgrading a large legacy codebase, Boot 4 provides a temporary bridge:

spring-boot-starter-classic
spring-boot-starter-test-classic

Use this to restore broad classpath coverage, fix imports/configs, then progressively move to focused starters.

Treat this as transitional, not the end state.

Jackson 3 migration: the highest-risk area

Boot 4 prefers Jackson 3 and introduces major ecosystem changes.

Key changes

Group/package migration from com.fasterxml.jackson to tools.jackson (with exceptions)
Boot integration class renames for consistency
Property namespace changes for JSON-specific read/write settings
Automatic registration of all classpath Jackson modules by default

Immediate risks

API payload differences (date/time formatting, null/default handling)
stricter or different deserialization outcomes
polymorphic payload regressions
subtle contract breakage across clients

Useful compatibility controls

Boot 4 adds transitional options:

spring.jackson.use-jackson2-defaults=true (closer behavior to Boot 3/Jackson 2 defaults)
spring-boot-jackson2 module as temporary stop-gap

Use these as migration aids, not long-term architecture.

Other migration changes teams miss

JSpecify nullability annotations can affect Kotlin/null-check tooling
Logback default charset behavior now aligned with UTF-8 expectations
BootstrapRegistry / EnvironmentPostProcessor package moves can break deep integrations
PropertyMapper no longer maps null source values by default (use always() when needed)
DevTools LiveReload now disabled by default
Optional Maven dependencies no longer included by default in uber jars

Recommended production migration strategy

Phase 1 — Stabilize

Upgrade to latest 3.5.x
Remove deprecations
Upgrade to Boot 4 with classic starters
Ensure app starts and core flows run

Phase 2 — Correctness

Add contract tests for JSON payloads
Verify Jackson behavior against real fixtures
Fix dependency graph explicitly (main + test)
Validate startup/runtime with production-like config

Phase 3 — Convergence

Replace classic starters with focused starters
Remove compatibility flags one by one
Re-check observability and actuator behavior
Final cleanup and docs update

CI/CD checks you should add before rollout

Dependency diff gate (3.5 vs 4.0)
Contract test stage for API payload compatibility
Integration tests with representative fixtures
Canary rollout + error budget guardrails
Fast rollback trigger on error spike

Practical checklist

[ ] Latest 3.5.x in production first
[ ] No known 3.x deprecations in code paths
[ ] Environment meets Java/Jakarta/Servlet requirements
[ ] Removed features audited (Undertow, etc.)
[ ] Jackson migration strategy selected (native vs transitional)
[ ] Starter and test-starter dependencies reviewed
[ ] Contract/integration tests green
[ ] Canary + rollback plan validated

Final takeaway

Spring Boot 4.0 gives a cleaner long-term model, but migration quality depends on discipline:

explicit dependencies,
explicit JSON behavior,
explicit rollout strategy.

If you treat it as a platform migration instead of a “version bump”, the upgrade is predictable and safe.

DEV Community: Titouan Despierres

Scaling Java 26 AI Workloads: A 2026 Production Playbook (GitOps & Kubernetes)

Scaling Java 26 AI Workloads: A 2026 Production Playbook (GitOps & Kubernetes)

1. The Java 26 Advantage: Why JDK 26 for AI?

Project Panama: Native Model Interaction

Virtual Threads (Loom) at Scale

2. The Build Pipeline: Containerizing JDK 26

Modern GitHub Actions Workflow

3. The GitLab CI Parallel: Enterprise Readiness

4. Kubernetes & GitOps: The Argo CD Pattern

The Kustomize Overlay

The Argo CD Application manifest

5. Observability & Rollout Strategies

Why Canary?

6. Adoption Strategy: How to Start

Conclusion

Optimizing Java AI Architectures for 2026: JDK 26, HTTP/3, and GitOps Control Planes

Optimizing Java AI Architectures for 2026: JDK 26, HTTP/3, and GitOps Control Planes

1. The Java Platform Shift: JDK 26 and HTTP/3

JEP 517: HTTP/3 for the HTTP Client API

JEP 516: Ahead-of-Time (AOT) Object Caching

2. CI/CD for AI Services: Unified Pipelines

Example: GitHub Actions for Java AI Deployment

3. Kubernetes & GitOps: The Argo CD Pattern

Practical Argo CD Application Manifest

4. Production Observability: The Feedback Loop

K8s Manifest for Advanced Scaling

5. Summary & Adoption Strategy

java #kubernetes #devops #ai

Optimizing Java AI Workloads on Kubernetes: A 2026 GitOps Playbook

Optimizing Java AI Workloads on Kubernetes: A 2026 GitOps Playbook

1. The Java 25 Edge: Native Memory & AI Frameworks

Practical Pattern: Resource Management in K8s

2. CI/CD: The Dual-Platform Strategy

GitHub Actions: Agentic Workflow Integration

GitLab CI: Multi-Project Pipelines for Platform Engineering

3. GitOps with Argo CD: The Progressive Rollout

Argo CD Rollout Manifest

4. Production Strategy: Observability & Rollback

Conclusion

java #kubernetes #devops #ai

Shipping Java AI Services on Kubernetes in 2026: A Practical CI/CD Playbook (GitHub Actions + GitLab CI + Argo CD)

Shipping Java AI Services on Kubernetes in 2026: A Practical CI/CD Playbook (GitHub Actions + GitLab CI + Argo CD)

1) Java in 2026: LTS strategy is now an architecture decision

What changed

Why it’s better

Trade-offs

Adoption strategy (production-safe)

2) AI in production: model choice became a platform concern, not an app concern

What changed

Why it’s better

Trade-offs

Practical Java pattern

3) Kubernetes: API drift and operations policy are now daily reality

What changed

Why it’s better

Trade-offs

Adoption strategy

4) CI/CD in 2026: from pipeline automation to delivery governance

GitHub Actions example (build + scan + push)

GitLab CI example (test + image + manifest update)

5) GitOps with Argo CD: make rollback boring

Core production pattern

Rollback strategy that actually works

6) A realistic 90-day adoption roadmap

Days 1–30: Stabilize the foundation

Days 31–60: Secure and govern delivery

Days 61–90: Optimize for speed and reliability

Final take

Replacing org.n52 JtsModule for Jackson 3: Introducing io.github.aytronnfr.jackson.jts.JtsModule

Replacing org.n52.jackson.datatype.jts.JtsModule for Jackson 3: Introducing io.github.aytronnfr.jackson.jts.JtsModule

TL;DR

Why this module exists

Compatibility targets

Dependency

Basic usage

Advanced usage: include bbox for selected geometry types

Migration notes from org.n52... module

Testing strategy used in the project

CI/CD and publishing

Replacing `org.n52.jackson.datatype.jts.JtsModule` for Jackson 3: Introducing `io.github.aytronnfr.jackson.jts.JtsModule`

Migration notes from `org.n52...` module