DZone Java Zone

Zero-Downtime Deployments for Java Apps on Kubernetes

Ramya vani Rayala — Fri, 29 May 2026 14:00:05 GMT

Zero-Downtime Deployments for Java Apps on Kubernetes

This article provides a comprehensive guide to achieving zero-downtime deployments for Java-based applications on Kubernetes.

We cover deployment strategies, Kubernetes primitives, Java-specific considerations, session state handling, database migrations, traffic shifting techniques, CI/CD pipelines, GitHub Actions, Jenkins with automated rollbacks, observability (Prometheus, Grafana, Jaeger), Helm/ArgoCD examples, testing strategies (canary analysis, chaos, smoke tests), and troubleshooting.

Deployment Strategies

Kubernetes offers several strategies for deploying new versions without downtime:

Rolling Update

Incrementally replace old pods with new ones, maintaining availability. Kubernetes Deployment object uses rolling updates by default. You can control maxUnavailable and maxSurge to tune the rollout.

Blue-Green Deployment

Run two separate environments: Blue = current, green = new. Only one serves live traffic at a time. Once the Green version is verified, switch the Service or Ingress to point at Green, then scale down Blue. This allows instant rollback by redirecting traffic back to Blue. Argo Rollouts defines a blue/green strategy with an active and preview Service. Traffic flows only to the active version until promotion.

Canary Deployment

Gradually shift a small percentage of traffic to the new version. Start with a few pods of v2, monitor, then incrementally increase. Tools like Istio or Argo Rollouts can control traffic weights. For instance, sending 10% of traffic to v2 can be done by running 9 v1 pods and 1 v2 pod (10%). Argo defines a canary rollout with setWeight steps and pauses for analysis.

Shadow/Mirroring

The new version receives a copy of live requests for testing under real load, but its responses are not returned to users. This is low risk but does not assist in rollback decisions since users don’t see the new behavior.

Kubernetes Primitives for Zero Downtime

Deployment

A Deployment naturally performs rolling updates. By default, it creates a new ReplicaSet and scales it up while scaling down the old one controlled by maxUnavailable/maxSurge. This ensures some pods always serve traffic. To use blue/green, you would deploy two separate Deployments (e.g., app-blue, app-green) and switch Services.

Service and Ingress

A Service fronts pods. For blue/green, you can point a single Service at either the blue or green pods. Ingress can also switch between backend services. E.g., label selectors can be adjusted to redirect traffic from version blue to version green pods.

PodDisruptionBudget

Ensures a minimum number of pods stay running during voluntary disruptions. For instance, setting minAvailable 1 ensures at least one pod remains during a rolling update. To avoid complete downtime during maintenance.

Horizontal Pod Autoscaler (HPA)

Scales pods based on CPU/memory or custom metrics. It automatically updates a workload to match demand. An HPA can be attached to the Deployment so that if traffic spikes during a rollout, new pods will be created to handle the load. Example:

apiVersion autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
         averageUtilization: 50

Liveness and Readiness Probes

Critical for zero downtime. A liveness probe checks if the app is alive; if it fails, K8 restarts the pod. A readiness probe tells if the app is ready to serve traffic. During startup or shutdown, the readiness probe should fail, causing the pod to be removed from the service load balancer. Spring Boot Actuator provides /actuator/health for this. In K8S YAML:

livenessProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

Spring Boot exposes health/liveness and health/readiness groups by default. Quarkus and Micronaut have similar health endpoints.

Spring Boot supports graceful shutdown by setting server.shutdown is equals to graceful and tuning spring.lifecycle.timeout-per-shutdown-phase. This causes the embedded server, either Tomcat/Jetty/Undertow, to stop accepting traffic and wait up to the timeout for active requests.

@Component
public class ShutdownListener implements SmartLifecycle {
    private boolean running = true;
    @Override public void stop() {
        running = false;
    }
    @Override public boolean isRunning() {
        return running;
    }
}

Quarkus provides graceful shutdown configuration. By setting quarkus.shutdown.timeout=10s, Quarkus will wait up to 10 seconds for current requests to finish before exiting. You can annotate a bean method with @Shutdown to run cleanup code.

Micronaut has @EventListener for ShutdownEvent:

@Singleton
public class ShutdownBean {
    @EventListener
    void onShutdown(ShutdownEvent event) {
    }
}

Kubernetes Hooks

You can use a preStop hook in the Deployment spec to run a script before SIGTERM.

lifecycle:
  preStop:
    exec:
      command: ["/bin/sh","-c","sleep 5"]
terminationGracePeriodSeconds: 30

The grace period (default 30s) should be tuned to let the app finish. K8S doc 77†L99-L107 describes the sequence container enters Terminating, runs preStop, sends SIGTERM, waits terminationGracePeriodSeconds, then SIGKILL.

JVM Tuning

Set -XX +ExitOnOutOfMemoryError to avoid hanging. Tune thread pools so they drain quickly. Monitor GC pause times, consider using low-latency GC to minimize pause before shutdown.

Session and State Handling

To maintain zero downtime when pods switch:

Stateless services: Best practice is to keep services stateless. Store session state or user data in an external store, such as Redis or a database. This way, any pod can handle any request, and pods can be replaced without losing the user session.
Sticky sessions: If an app uses in-memory sessions, you can enforce sticky sessions
Service affinity: Set sessionAffinity: ClientIP on the Service. Kubernetes routes requests from the same client IP to the same pod.
Ingress affinity: Use Ingress annotations to bind a user’s requests to one pod. However, sticky sessions introduce risk and are not suitable for autoscaling.
StatefulSets: For true stateful workloads, use StatefulSet with stable identities. StatefulSets pair pods with PersistentVolumes, which are not zero-downtime by themselves.

GitHub Actions CI/CD Pipeline zero-downtime:

name: Deploy

on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-java@v3
        with: { java-version: '17' }
      - name: Build
        run: mvn clean package -DskipTests
       name: Docker Build & Push
        run: |
          docker build -t ghcr.io/myorg/myapp:${{ github.sha }}
          echo ${{ secrets.GITHUB_TOKEN }} | docker login ghcr.io -u ${{ github.actor }} --password-stdin
          docker push ghcr.io/myorg/myapp:${{ github.sha }}
      - name: Set image tag
        run: echo "::set-output name=image::ghcr.io/myorg/myapp:${{ github.sha }}

  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with: { path: manifests }
      - name: Update K8s deployment
        uses: azure/setup-kubectl@v3
      - name: Deploy to Kubernetes
        run: |
          kubectl set image deployment/myapp-deployment myapp=ghcr.io/myorg/myapp:${{ needs.build.outputs.image }}
          kubectl rollout status deployment myapp-deployment

This workflow builds the image, pushes it, and updates the deployment. The rollout status command waits for all new pods to become ready. If health checks fail, it will abort without downtime.

Conclusion

Zero-downtime deployment on Kubernetes combines careful architecture and automation, using rolling updates, progressive strategies, ensuring graceful shutdown and health checks in your Java apps, externalizing state, managing database changes, and orchestrating with CI/CD pipelines. Kubernetes primitives like Deployments, Services, Probes, and HPA, along with tools like Istio or Argo Rollouts, provide the building blocks.

Opinions expressed by DZone contributors are their own.

Generated by Readability.php.

Pragmatica Aether: Let Java Be Java

Sergiy Yevtushenko — Fri, 29 May 2026 13:00:09 GMT

Pragmatica Aether: Let Java Be Java

The Aberration

We build Java applications like Go or Rust programs. Fat JARs. Docker images. Kubernetes deployments. Everyone does it, so it looks normal.

It contradicts Java’s design DNA.

Java has always been a language for managed environments. Applets ran inside browsers. Servlets ran inside application servers. EJBs ran inside containers like JBoss and WebLogic. OSGi bundles ran inside runtime containers like Eclipse Equinox. In every generation, the pattern was the same: a managed runtime hosts the application. The application handles business logic. The runtime handles infrastructure.

The fat-jar era threw that away. We stopped letting Java be Java. We started bundling web servers, serialization frameworks, service discovery clients, configuration management, health checks, metrics libraries, and logging frameworks into every application. Then we wrapped the result in a Docker container and deployed it to an orchestration platform that reimplements — poorly — the infrastructure management that Java runtimes used to provide natively.

This article introduces Pragmatica Aether: a distributed runtime that returns Java to its natural habitat. The application handles business logic. Runtime handles infrastructure. This isn’t radical — it's returning to what Java was designed for.

The Problem: Infrastructure Wearing a Business Logic Mask

Think of what a typical Java microservice carries. A web server (Tomcat, Netty, Undertow). A serialization framework (Jackson, Gson). A dependency injection container (Spring, Guice). A service discovery client (Eureka, Consul). Health check endpoints. Configuration management (Spring Cloud Config, Consul KV). A metrics library (Micrometer, Dropwizard). A logging framework (Logback, Log4j2). Retry logic (Resilience4j). Circuit breakers. HTTP client configuration. The application is wearing a heavy winter coat of infrastructure, armed to the teeth to survive in a hostile environment.

Now consider the coupling this creates.

Update the Java version — rebuild and test every service. Change your message broker from RabbitMQ to Kafka — modify, rebuild, and redeploy every application that touches messaging. Add a new observability tool and update dependencies in every microservice. Switch cloud providers — rewrite configuration, SDK calls, and deployment manifests across the entire fleet. Each change ripples through dozens or hundreds of services because infrastructure is entangled with business logic at the dependency level.

This is the coupling trap. Your application’s pom.xml doesn't distinguish between business dependencies and infrastructure dependencies. They compile together, deploy together, and break together. A security patch in Netty requires a new build of every service that embeds a web server, which is all of them.

Framework lock-in worsens this. It isn’t a vendor problem — it's an architecture problem. Spring’s dependency injection fights with Kubernetes service mesh for control over service routing and circuit breaking. The framework’s configuration system overlaps with Consul KV and Kubernetes ConfigMaps. Your cloud SDK’s retry logic conflicts with Resilience4j. Every layer claims authority over the same cross-cutting concerns, and the conflicts surface as subtle bugs in production — not during development.

This is an architecture problem. Architectural problems have architectural solutions.

Aether: The Core Idea

What you write: an interface annotated with @Slice, plus business logic implementation.

@Slice
public interface OrderService {
    Promise<OrderResult> placeOrder(PlaceOrderRequest request);

    static OrderService orderService(InventoryService inventory, PricingEngine pricing) {
        return request -> inventory.check(request.items())
                                   .flatMap(available -> pricing.calculate(available))
                                   .map(priced -> OrderResult.placed(priced));
    }
}

What you don’t write: everything else.

No HTTP clients — inter-slice calls are direct method invocations via generated proxies. No service discovery — the runtime tracks where every slice instance lives. No retry logic — built-in retry with exponential backoff and node failover. No circuit breakers — the reliability fabric handles failure automatically. No serialization code — request/response types are serialized transparently.

A method call via an imported interface is the only visible contract. The only hint that the actual call might be remote is a design requirement: slice methods should be idempotent. This isn’t a limitation — it's what enables retry, scaling, and fault tolerance to work transparently. The same request, processed by any available instance, produces the same result. Most read operations are naturally idempotent. For writes, standard patterns like idempotency keys and conditional writes handle it cleanly.

Everything else is the environment’s job: resource provisioning, scaling, transport, discovery, retries, circuit breakers, configuration, observability, logging, tracing, monitoring, and security. None of these are application concerns, and none should be handled at the business logic level.

The JBCT Leaf pattern serves two purposes here: it documents the design (“what we expect from an external implementation”) and encourages exactly one interface per dependency. Different implementations may have different technical properties — performance, latency, memory consumption — but as long as they’re compatible with the interface, business logic works unchanged.

You write basically pure business logic that scales from your local computer to a global multi-zone distributed deployment, transparently.

Under The Hood: What Makes It Work

Five architectural decisions make this possible.

Consensus KV Store. A single source of truth for all configuration, deployment state, and service discovery. Based on the Rabia protocol, a crash-fault-tolerant, leaderless consensus algorithm was published in 2021. Any node can propose; agreement is reached through a two-round voting protocol with a fast path when a supermajority agrees in round one. No external config servers. No etcd. No Consul. Configuration changes propagate through consensus and take effect cluster-wide.

Built-in Artifact Repository. DHT-based storage with configurable replication — 3 replicas with quorum reads/writes in production, full replication in development. Artifacts are chunked into 64KB pieces, distributed across nodes via consistent hashing, and integrity-verified with MD5 and SHA-1 on every resolve. No external Nexus or Artifactory is needed. During development, slices resolve from your local Maven repository. In production, the cluster is self-contained.

ClassLoader Isolation. Each slice runs inside its own SliceClassLoader with child-first delegation. Two slices can use different versions of the same library without conflict. Shared dependencies like Pragmatica Lite core are loaded once in a parent classloader. No dependency conflicts. No classpath hell between slices.

Declarative Deployment. Blueprints — TOML files — describe the desired state: which slices, how many instances.

id = "org.example:commerce:1.0.0"

[[slices]]
artifact = "org.example:inventory-service:1.0.0"
instances = 3

[[slices]]
artifact = "org.example:order-processor:1.0.0"
instances = 5

Apply with one command: aether blueprint apply commerce.toml. The cluster resolves artifacts, loads slices, distributes instances across nodes, registers routes, and starts serving traffic. The cluster converges to the desired state automatically.

Infrastructure Independence. Aether nodes are identical — there's only one deployment artifact to manage at the infrastructure level. Node updates and application deployments run on completely independent schedules. Update Java — roll it out across nodes without touching applications. Update the Aether runtime — same. Update business logic — deploy new slice versions without touching infrastructure. Each independently, each without downtime. This is the fundamental benefit of proper separation: when layers don’t share a deployment unit, they don’t share a deployment schedule.

Fault Tolerance: The 50% Rule

The system survives the failure of less than half the nodes. Performance may degrade until replacements spin up, but functionality remains intact — actual redundancy, not just graceful degradation. A 5-node cluster tolerates 2 simultaneous failures. A 7-node cluster tolerates 3. The same request, processed by any available node, produces the same result. Quorum requires (N/2) + 1 nodes — as long as a majority is alive, the cluster operates normally.

Leader failover is consensus-based and near-instant. Node replacement happens automatically — the Cluster Deployment Manager detects the deficit and provisions a replacement through the NodeProvider interface. The entire recovery sequence — from failure detection through state restoration to serving traffic — completes without human intervention.

When a node fails, the recovery is automatic. Requests to slices on the failed node are immediately retried on healthy nodes. A replacement node is provisioned. It connects to peers, restores consensus state from a cluster snapshot, re-resolves artifacts from the DHT, and reactivates assigned slices. Dead nodes are automatically removed from routing tables. The new leader reconciles the stale state. No human intervention required.

Rolling updates leverage this fault tolerance for zero-downtime deployments with weighted traffic routing:

aether update start org.example:order-processor 2.0.0 -n 3
aether update routing <id> -r 1:3    # 25% to v2, 75% to v1
aether update routing <id> -r 1:1    # 50/50
aether update complete <id>          # 100% to v2, drain v1

Deploy during business hours. Shift traffic gradually — 10% canary, then 25%, 50%, 75%, 100%. Monitor health metrics at each step. If health degrades — error rate exceeds thresholds, latency spikes — instant rollback with one command: aether update rollback <id>. Traffic immediately shifts back to the old version. The 3 AM pager alert becomes an audit log entry.

For Every Project: Legacy, Greenfield, And Everything Between

Legacy Migration

Your legacy Java system doesn’t need a complete rewrite. It needs a path forward.

Pick a relatively independent part of your system — something hitting limits, something with clear boundaries. Extract an interface. Annotate it with @Slice. Wrap the legacy implementation:

private Promise<Report> generateReport(ReportRequest request) {
    return Promise.lift(() -> legacyReportService.generate(request));
}

One line to enter the Aether world. Promise.lift() wraps the legacy call, catches exceptions, and returns a proper Result inside a Promise. Your legacy code keeps running. Call sites don't change. You haven't added risk — the initial deployment in Ember runs in the same JVM as your existing application, which means it's no worse than what you have today. You've laid the foundation for removing risk, not adding it. Moving from Ember to a full Aether cluster is a configuration change, not a code change — and that's when the 50% rule starts to apply.

From there, it’s the strangler fig pattern. Extract a hot path, deploy it as a slice, route traffic, repeat. Each extracted slice can be gradually refactored using the peeling pattern: first wrap everything in Promise.lift(), then decompose into a Sequencer with each step still wrapped, then peel individual steps into clean JBCT patterns. Tests pass at every step. The lift() calls mark exactly where legacy code remains, making progress visible and remaining work obvious.

No rewrite is required. No big bang migration. One sprint to the first slice in production. The migration article covers the full path in detail — from initial wrapping through gradual peeling to clean JBCT code.

Greenfield Development

For new projects, slices enable a granularity that’s impossible with traditional microservices.

Each slice can be as lean as a single method — and that’s the recommended approach. There are no operational or complexity tradeoffs for small slices because Aether handles all the infrastructure overhead. No container to configure, no load balancer to provision, no monitoring to set up per service. You get per-use-case scaling: one slice serving 50 instances during peak load while another idles at minimum. That kind of granularity would be operationally insane with traditional microservices — each needing its own container, load balancer, monitoring, and deployment pipeline. With Aether, it’s the default.

JBCT patterns — Leaf, Sequencer, Fork-Join, Condition, Iteration, and Aspects — compose naturally within slices. Each slice method is a data transformation pipeline: parse input, gather data, process, respond. The patterns provide consistent structure within slices. Slices provide consistent boundaries between them.

The Spectrum

Same slice model, different granularity. A service slice wraps an entire legacy component. A lean slice implements a single method. Both coexist in the same cluster, deployed and scaled independently.

Slice is the executable unit. It can be big or small as necessary and convenient. The architecture accommodates both monolith migration and greenfield development simultaneously. Your legacy system gains fault tolerance while new features get maximum deployment flexibility.

Scaling: Two Levels, Three Tiers of Intelligence

Two-Level Horizontal Scaling

Aether scales in two dimensions independently:

Slice scaling: Spin up more instances of a specific slice on existing nodes. Classes are already loaded—scaling takes milliseconds, not seconds.
Node scaling: Add more machines to the cluster. The node connects, restores state, and begins accepting work.

Independent controls, combined effect. Each node hosts at most one instance of a given slice, so scaling a slice beyond the current node count requires adding nodes first. Add 2 more nodes to a 3-node cluster, then scale a hot slice to 5 instances—one per node. No coordination between the two dimensions is required.

Three-Tier Decision System

Tier 1—Decision Tree (1-second intervals)

Instant reactive decisions based on CPU utilization, request latency, queue depth, and error rate. CPU above 70%? Add an instance. Below 30% sustained? Remove one (if above minimum). Latency exceeding the P95 threshold? Scale up. Error rate above 1% due to timeouts? Scale up. Deterministic, predictable, fast. Handles routine load changes with configurable cooldown periods — 30 seconds for scale-up, 5 minutes for scale-down — to prevent oscillation.

Tier 2—TTM Predictor (60-second intervals)

An ONNX-based machine learning model (Tiny Time Mixers) analyzes a 60-minute sliding window of metrics — CPU usage, request rate, P95 latency, and active instances. Forecasts load and adjusts the Decision Tree’s thresholds preemptively. If TTM predicts a load increase, it lowers the scale-up CPU threshold by 20% so the reactive tier responds earlier. The cluster scales before the spike arrives, not after. The key design principle: the cluster always survives on Tier 1 alone. TTM enhances; it doesn’t replace. If TTM fails — model load error, insufficient data, inference failure — the Decision Tree continues with default thresholds. The error is logged and recorded in metrics. No scaling disruption.

Tier 3—LLM-based (planned)

Long-term capacity planning and cluster health monitoring. Seasonal pattern prediction, maintenance window planning, anomaly investigation. This tier is not yet implemented — the current system operates with Tiers 1 and 2.

Fault tolerance makes preemptible instances viable for burst scaling. If a spot instance gets reclaimed, the cluster survives — it was designed for nodes to disappear.

You don’t need a PhD in distributed systems or a dedicated platform team. The scaling system manages itself.

Development Experience: From Laptop To Production

Three Environments, Zero Code Changes

Ember

Single-process runtime with multiple cluster nodes running in the same JVM. Fast startup, simple debugging. Deploy your slices alongside your existing application — slices call each other directly in-process. No network overhead. Standard debugger breakpoints work as expected. Perfect for local development and unit testing.

Forge

A 5-node cluster simulator running on your laptop. Real consensus. Real routing. Real failure scenarios. Kill nodes, crash the leader, trigger rolling restarts — and watch the cluster recover in real time through a web dashboard with D3.js topology visualization, per-node metrics (CPU, heap, leader status), and event timeline. Configurable load generation with TOML-based multi-target configuration lets you stress-test realistic scenarios — set request rates, define body templates, and run duration-limited load tests. Chaos operations include node kill, leader kill, and rolling restart. Forge validates the entire dependency graph before starting anything.

Aether

Production cluster. Same slices, same code, different scale. Your code doesn’t know which environment it’s running in. Whether inter-slice calls are in-process or cross-network is transparent.

Tooling

37 CLI commands cover deployment, scaling, updates, artifacts, observability, controller configuration, and alerts — in both single-command and interactive REPL modes. A web dashboard streams real-time metrics via WebSocket — no polling. 30+ REST management endpoints enable full programmatic control of everything the CLI can do. Prometheus-compatible metrics export (/metrics/prometheus) integrates with existing monitoring stacks.

Metrics are push-based at 1-second intervals, with zero consensus overhead — they bypass the consensus protocol entirely. Per-method invocation tracking with P50/P95/P99 latency and configurable slow-invocation detection strategies (fixed threshold, adaptive, per-method, composite) surfaces performance issues before users notice. Dynamic aspects let you toggle LOG/METRICS/LOG_AND_METRICS modes per method at runtime via REST API, without redeployment.

Test realistic failure scenarios on your laptop. Deploy to production with a config change, not a code change.

Maturity

Aether is a working system, not a concept paper.

81 end-to-end tests are run against real 5-node clusters in Podman containers, validating cluster formation, quorum establishment, slice deployment and scaling, blueprint application with topological ordering, multi-instance distribution, artifact upload, and cross-node resolution with integrity verification, leader failure and recovery, node restart with state restoration, and orphaned state cleanup after leader changes.

The recovery and fault tolerance claims come from automated tests against real clusters, not marketing slides.

Let Java Be Java

Java’s lineage leads here. From applets managed by browsers, through servlets managed by application servers, through EJBs managed by enterprise containers, through OSGi managed by runtime frameworks, to Aether, managed by a distributed runtime.

The fat-jar era was a detour. An understandable one — when Docker emerged, it offered a universal packaging format, and the industry standardized on it regardless of language. Java adopted the patterns of languages that were designed to produce standalone binaries. We started treating Java applications like Go programs with a heavier runtime. But it was never the destination. Java was designed for managed environments. The JVM makes it possible. The runtime manages the application. That’s the lineage. Aether continues it.

Two entry points exist today. Wrap your legacy monolith behind a @Slice interface in one sprint and gain fault tolerance without rewriting anything. Or start fresh with maximum clarity — lean slices, explicit contracts, per-use-case scaling. Both paths converge on the same runtime, the same cluster, the same operational model. Both paths can coexist — legacy service slices and new lean slices running side by side.

Fault tolerance is not an afterthought — it's the foundation. Scaling is not your problem — it's the environment’s. Infrastructure is not your code — it's the runtime’s. The heavy winter coat comes off. The application breathes.

Resources

Pragmatica Aether—project site
GitHub Repository—source code

Generated by Readability.php.

Stateless JWT Auth Microservice Architecture With Spring Boot 3 and Redis Sentinel

Erkin Karanlık — Wed, 27 May 2026 19:00:00 GMT

Stateless JWT Auth With Spring Boot 3 & Redis Sentinel

In this article, I will discuss a highly available solution developed using Spring Boot 3 and Spring Security 6 to address the "centralized authentication method" problem frequently seen in modern microservice ecosystems.

We are not simply moving to an "authorization service"; we are examining the cache-first pattern, which minimizes DB usage, and the Redis Sentinel enhancement, which guarantees system persistence.

Why a Separate Authentication Service?

While embedding security into each service is an option in microservices, I have always found it more logical to proceed with a centralized Auth service and API Gateway combination.

DRY (Don't Repeat Yourself): Using token authentication logic in many services increases extra maintenance costs.
Isolation: Business services focus only on business logic; they don't deal with "is this token valid?" questions.
Performance: Thanks to the Redis connection, instead of going to the database with every request, we can resolve the validation via the cache in milliseconds.

[Client] ──► [API Gateway] ──► [Auth Service: validate token]
                                         │ (valid)
                                         ▼
                              [Backend Microservices]

Cache-Focused Approach: Reducing Database Load

In the classic workflow, every login request puts a load on the DB.

With the cache-first approach, the process proceeds like this with a POST /auth/signin request:

First, Redis is checked. If there is a valid and unexpired token for the user, it is replicated directly. In case of cache deficiency, AuthManager.authenticate() is activated, a DB query is sent, and a BCrypt check is performed.

After a successful login, a token is generated with JJWT (HS256). This token is given to Redis with our changes and TTL (e.g., 24 minutes), and personal responses are converted. In this way, it protects our main database, especially in brute-force or high-intensity login password attacks.

POST /auth/signin
        │
        ▼
┌──────────────────────────────┐
│  Token exists in Redis?      │──── YES ──► Return token (0 DB queries)
└──────────────────────────────┘
        │ NO
        ▼
┌──────────────────────────────┐
│  AuthManager.authenticate()  │  (DB query + BCrypt verification)
└──────────────────────────────┘
        │
        ▼
┌──────────────────────────────┐
│  Generate JWT (JJWT HS256)   │
└──────────────────────────────┘
        │
        ▼
┌──────────────────────────────┐
│  Write to Redis (TTL: 24 min)│
└──────────────────────────────┘
        │
        ▼
   Return token

Implementation Details

User Entity and UserDetails Integration

In most projects, unnecessary mappings are performed between the User asset and the UserDetails objects expected by Spring Security. To reduce complexity, the User Entity is directly derived from the UserDetails interface. This makes the code cleaner and makes it "native," as outlined by Spring Security.

@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
@Entity
@Table(name = "T_APP_USER")
public class User implements UserDetails {

    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "seq_user_gen")
    @SequenceGenerator(name = "seq_user_gen", sequenceName = "SEQ_APP_USER", allocationSize = 1)
    @Column(name = "idx")
    private Long idx;

    @Column(name = "firstname")  private String firstName;
    @Column(name = "lastname")   private String lastName;
    @Column(unique = true, name = "email")   private String email;
    @Column(name = "accesskey")  private String accessKey;  // BCrypt-hashed

    @Column(name = "role")
    @Enumerated(EnumType.STRING)
    private Role role;

    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {
        return List.of(new SimpleGrantedAuthority(role.name()));
    }

    @Override public String getUsername()              { return email; }
    @Override public String getPassword()              { return accessKey; }
    @Override public boolean isAccountNonExpired()     { return true; }
    @Override public boolean isAccountNonLocked()      { return true; }
    @Override public boolean isCredentialsNonExpired() { return true; }
    @Override public boolean isEnabled()               { return true; }
}

JWT Filter: The Gateway to Security

The request to the system passes through the OncePerRequestFilter.

Here, using JwtAuthenticationFilter, we parse the token in each request and populate the SecurityContext. By using the new SecurityFilterChain bean introduced with Spring Security 6, we have disabled CSRF and made session management completely stateless.

Token Generation and Validation

public interface JwtService {
    String extractUserName(String token);
    String generateToken(UserDetails userDetails);
    boolean isTokenValid(String token, UserDetails userDetails);
}

@Service
public class JwtServiceImpl implements JwtService {

    @Value("${token.signing.key}")
    private String jwtSigningKey;  // Base64-encoded secret key

    @Override
    public String extractUserName(String token) {
        return extractClaim(token, Claims::getSubject);
    }

    @Override
    public String generateToken(UserDetails userDetails) {
        return Jwts.builder()
            .setClaims(new HashMap<>())
            .setSubject(userDetails.getUsername())
            .setIssuedAt(new Date(System.currentTimeMillis()))
            .setExpiration(new Date(System.currentTimeMillis() + 1000 * 60 * 24)) 
            .signWith(getSigningKey(), SignatureAlgorithm.HS256)
            .compact();
    }

    @Override
    public boolean isTokenValid(String token, UserDetails userDetails) {
        final String userName = extractUserName(token);
        return userName.equals(userDetails.getUsername()) && !isTokenExpired(token);
    }

    private <T> T extractClaim(String token, Function<Claims, T> claimsResolver) {
        return claimsResolver.apply(
            Jwts.parserBuilder()
                .setSigningKey(getSigningKey())
                .build()
                .parseClaimsJws(token)
                .getBody()
        );
    }

    private boolean isTokenExpired(String token) {
        return extractClaim(token, Claims::getExpiration).before(new Date());
    }

    private Key getSigningKey() {
        return Keys.hmacShaKeyFor(Decoders.BASE64.decode(jwtSigningKey));
    }
}

High Availability: Redis Sentinel

Using a single Redis instance means that the Auth service has a "Single Point of Failure." If Redis crashes, no one can access the system. This risk mitigation was achieved using Redis Sentinel.

Thanks to the Sentinel structure: If the master node crashes, the dependent node is automatically promoted to master via failover. On the application side, we continuously manage these transitions using the Lettuce driver.

Technical Stack and Requirements

Redis Sentinel configuration:

@Configuration
public class RedisConfig {

    @Value("${spring.redis.sentinel.master}")
    private String master;

    @Value("${spring.redis.sentinel.nodes}") 
    private String sentinelNodes;

    @Value("${spring.redis.password}")
    private String password;

    @Bean
    public RedisConnectionFactory redisConnectionFactory() {
        RedisSentinelConfiguration sentinelConfig = new RedisSentinelConfiguration()
                .master(master);

        for (String node : sentinelNodes.split(",")) {
            String[] hostPort = node.split(":");
            sentinelConfig.sentinel(hostPort[0], Integer.parseInt(hostPort[1]));
        }

        sentinelConfig.setPassword(RedisPassword.of(password));
        return new LettuceConnectionFactory(sentinelConfig);
    }
}

yaml
  
 env:
   - name: spring.redis.sentinel.master
     valueFrom:
       secretKeyRef:
        name: redis-user-secret
         key: username
   - name: spring.redis.password
     valueFrom:
       secretKeyRef:
         name: redis-user-secret
         key: password

Token cache service:

@Service
public class TokenCacheServiceImpl {

    private final RedisTemplate<String, String> redisTemplate;

    public TokenCacheServiceImpl(RedisTemplate<String, String> redisTemplate) {
        this.redisTemplate = redisTemplate;
    }

    public void cacheToken(String username, String token, long duration, TimeUnit unit) {
        redisTemplate.opsForValue().set(username, token, duration, unit);
    }

    @Cacheable(value = "tokens", key = "#username")
    public String getToken(String username) {
        return redisTemplate.opsForValue().get(username);
    }
}

Authentication service: signup and signin:

@Service
@RequiredArgsConstructor
public class AuthenticationServiceImpl implements AuthenticationService {

    private final UserRepository userRepository;
    private final PasswordEncoder passwordEncoder;
    private final JwtService jwtService;
    private final AuthenticationManager authenticationManager;
    private final TokenCacheServiceImpl tokenCacheService;

    @Override
    public JwtAuthenticationResponse signup(SignUpRequest request) {
        var user = User.builder()
            .firstName(request.getFirstName())
            .lastName(request.getLastName())
            .email(request.getEmail())
            .accessKey(passwordEncoder.encode(request.getAccessKey())) // BCrypt
            .role(Role.USER)
            .build();

        userRepository.save(user);
        var jwt = jwtService.generateToken(user);
        return JwtAuthenticationResponse.builder().token(jwt).build();
    }

    @Override
    public JwtAuthenticationResponse signin(SigninRequest request) {
        // 1. Check Redis cache first
        String cachedToken = tokenCacheService.getToken(request.getEmail());
        if (cachedToken != null) {
            return JwtAuthenticationResponse.builder().token(cachedToken).build();
        }

        // 2. If not cached, authenticate (DB + BCrypt)
        authenticationManager.authenticate(
            new UsernamePasswordAuthenticationToken(request.getEmail(), request.getAccessKey())
        );

        var user = userRepository.findByEmail(request.getEmail())
            .orElseThrow(() -> new IllegalArgumentException("Invalid credentials."));

        // 3. Generate token and write to Redis (24 min TTL)
        var jwt = jwtService.generateToken(user);
        tokenCacheService.cacheToken(request.getEmail(), jwt, 24, TimeUnit.MINUTES);
        return JwtAuthenticationResponse.builder().token(jwt).build();
    }
}

JWT authentication filter:

@Component
@RequiredArgsConstructor
public class JwtAuthenticationFilter extends OncePerRequestFilter {

    private final JwtService jwtService;
    private final UserService userService;

    @Override
    protected void doFilterInternal(
        @NonNull HttpServletRequest request,
        @NonNull HttpServletResponse response,
        @NonNull FilterChain filterChain
    ) throws ServletException, IOException {

        final String authHeader = request.getHeader("Authorization");

        // Pass through if no Authorization header or doesn't start with Bearer
        if (StringUtils.isEmpty(authHeader) || !StringUtils.startsWith(authHeader, "Bearer ")) {
            filterChain.doFilter(request, response);
            return;
        }

        final String jwt = authHeader.substring(7);
        final String userEmail = jwtService.extractUserName(jwt);

        // Process only if SecurityContext has no authentication yet
        if (StringUtils.isNotEmpty(userEmail)
                && SecurityContextHolder.getContext().getAuthentication() == null) {

            UserDetails userDetails = userService.userDetailsService()
                    .loadUserByUsername(userEmail);

            if (jwtService.isTokenValid(jwt, userDetails)) {
                SecurityContext context = SecurityContextHolder.createEmptyContext();
                UsernamePasswordAuthenticationToken authToken =
                    new UsernamePasswordAuthenticationToken(
                        userDetails, null, userDetails.getAuthorities()
                    );
                authToken.setDetails(new WebAuthenticationDetailsSource().buildDetails(request));
                context.setAuthentication(authToken);
                SecurityContextHolder.setContext(context);
            }
        }

        filterChain.doFilter(request, response);
    }
}

Spring Security 6 configuration:

@Configuration
@EnableWebSecurity
@RequiredArgsConstructor
public class SecurityConfiguration {

    private final JwtAuthenticationFilter jwtAuthenticationFilter;
    private final UserService userService;

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
            .csrf(AbstractHttpConfigurer::disable)           // Stateless → no CSRF needed
            .authorizeHttpRequests(request -> request
                .requestMatchers("/auth/**").permitAll()      // Auth endpoints open to all
                .anyRequest().authenticated()
            )
            .sessionManagement(manager ->
                manager.sessionCreationPolicy(STATELESS)     // No server-side session
            )
            .authenticationProvider(authenticationProvider())
            .addFilterBefore(jwtAuthenticationFilter,        // JWT filter runs first
                UsernamePasswordAuthenticationFilter.class);

        return http.build();
    }

    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }

    @Bean
    public AuthenticationProvider authenticationProvider() {
        DaoAuthenticationProvider authProvider = new DaoAuthenticationProvider();
        authProvider.setUserDetailsService(userService.userDetailsService());
        authProvider.setPasswordEncoder(passwordEncoder());
        return authProvider;
    }

    @Bean
    public AuthenticationManager authenticationManager(AuthenticationConfiguration config)
            throws Exception {
        return config.getAuthenticationManager();
    }
}

Unit tests:

@Test
@DisplayName("Signin: if token is cached, should not query the DB")
void testSignInWithCachedToken() {
    when(tokenCacheService.getToken(TEST_EMAIL)).thenReturn(TEST_TOKEN);

    JwtAuthenticationResponse response = authenticationService.signin(
        SigninRequest.builder().email(TEST_EMAIL).accessKey(TEST_PASSWORD).build()
    );

    assertEquals(TEST_TOKEN, response.getToken());
    verifyNoInteractions(authenticationManager);  // No DB + BCrypt call should happen
    verifyNoInteractions(userRepository);
}

// Invalid token test — SecurityContext should remain empty
@Test
@DisplayName("With an invalid token, SecurityContext should remain empty")
void testDoFilterInternalInvalidToken() throws Exception {
    when(request.getHeader("Authorization")).thenReturn("Bearer " + INVALID_TOKEN);
    when(jwtService.extractUserName(INVALID_TOKEN)).thenReturn(TEST_EMAIL);
    when(userService.userDetailsService()).thenReturn(userDetailsService);
    when(userDetailsService.loadUserByUsername(TEST_EMAIL)).thenReturn(userDetails);
    when(jwtService.isTokenValid(INVALID_TOKEN, userDetails)).thenReturn(false);

    jwtAuthenticationFilter.doFilterInternal(request, response, filterChain);

    verify(filterChain).doFilter(request, response);
    assertNull(SecurityContextHolder.getContext().getAuthentication());
}

Summary and Conclusion

With the purchasing architecture, not only a secure login screen; It has built an architecture that is extremely scalable, overcomes database bottlenecks with caching, and meets high availability (HA) standards.

In particular, the modern architecture offered by Spring Boot 3 has made the security layer much more flexible. If you are starting a large-scale microservice project, you can design token management from the outset in this "stateless" and "cached" manner.

Opinions expressed by DZone contributors are their own.

Generated by Readability.php.

Rethinking Java CRUDs With Event Sourcing and CQRS Patterns

Nicolas Duminil — Tue, 26 May 2026 15:30:13 GMT

Rethink Java CRUDs With Event Sourcing and CQRS Patterns

Traditional CRUD systems store only the current state of an entity. When a record is updated, the previous value is overwritten and lost forever. Event Sourcing inverts this model: instead of persisting state, the system persists the sequence of events that caused each state transition. The current state is never stored directly, but it is always derived by replaying the event history.

Command Query Responsibility Segregation (CQRS) separates the write model from the read model. A command expresses intent to change state, for example PlaceOrder, AddItem, ShipOrder. A query reads state without modifying it. The two sides use separate models, separate logic, and, in a full implementation, separate storage.

CQRS and event sourcing are complementary: the event stream is the write side's source of truth, while one or more projections (read models) are derived from those events for fast querying.

This article aims at showing how to apply, in practice, these concepts, using for illustration purposes a modified version of one of Markus Eisele's article, from the 27th of December 2025 on Substack. In his article, Markus shows a Quarkus-based project implementing a simplified order management system. Here, I'm presenting the Spring Boot implementation of this same system, to change. You can find it here.

Terminology

In a *classical* order management system, by analyzing the associated data model, we can gather a lot of information about orders and their flow in the organization. But while we would be able to account for any order's current status, the data and the data model analysis wouldn't allow us to reconstitute the story of how each order got to its current state.

Event Sourcing

The event sourcing pattern introduces the dimension of time into the data model. Instead of a schema reflecting the orders' current state, an event-sourcing-based system persists events documenting every change in the orders' lifecycle. Then, by querying these events, we can reconstitute the whole story of a given order, or any other general aggregate, from its initial creation until its current status.

CQRS

The only problem here is that querying a single aggregate instance event story at a time doesn't allow us to retrieve and consolidate data relative to other aggregates in the data model. Hence, the CQRS pattern is closely related to the event sourcing one, designed to provide the possibility of materializing

projected models into logical data structures, reliable enough to support flexible querying options.

Commands

CQRS dedicates commands to execute operations that modify the system state. The command-based execution model is then the only one able to implement business logic, to validate rules, and to enforce invariants.

Projections

The system can define as many models as required to provide data to users or to other systems. Thus, a read model is a fast, denormalized, and pre-cached projection containing read-only data that the application needs to answer queries. The system project changes from the command execution model to all its read models. The projection notion is similar to that of a materialized view in relational databases, meaning that whenever the source tables are updated, the changes have to be reflected in all the read model views.

Model Segregation

In a CQRS architecture, the responsibilities of the system's models are segregated according to their type. A command can only operate on its own execution model, while a query cannot directly modify any of the system's persisted state.

A Use Case

The use case presented here is a *true* CQRS implementation (not just a naming convention) because:

The write path never reads from the read model. CommandHandler reconstructs state exclusively by replaying events from the event store via EventProjection.replayEvents(). It never touches OrderReadModel or OrderRepository.
The read path never touches the event store. OrderResource.getOrderReadModel() reads directly from the denormalized ORDERS table. It is a pure query with no business logic.
There are two physically distinct storage tables: EVENT_STORE (write side) and ORDERS (read side).
The read model is a projection, not a view. OrderProjection listens to domain events and rebuilds the read model incrementally. The ORDERS table could be dropped and rebuilt from scratch by replaying the event store.
Commands return CommandResult, a sealed type that communicates success or failure without leaking state. The caller must query the read model separately if it needs current state.

Let's look now at the project's key implementation details:

Modeling State With Records

OrderState is a Java record immutable by construction. No setters, no mutation. Every command produces a *new* state object:

public record OrderState(
  UUID orderId,
  String customerEmail,
  List<OrderLine> items,
  OrderStatus status,
  BigDecimal total
) {
    public static OrderState initial(UUID orderId, String email) { ... }
    public static OrderState empty() { ... }
  }

OrderLine is likewise a record with a derived field:

public record OrderLine(String productName, int quantity, BigDecimal price) 
{
  public BigDecimal lineTotal() 
  {
    return price.multiply(BigDecimal.valueOf(quantity));
  }
}

lineTotal() is a derived record component: it is computed, not stored, demonstrating that records can carry behavior alongside.

Events as a Sealed Type Hierarchy

OrderEvent is a sealed interface, restricting all permitted implementations to a known, closed set:

public sealed interface OrderEvent
  permits OrderEvent.OrderPlaced,OrderEvent.ItemAdded,
    OrderEvent.ItemRemoved,OrderEvent.OrderCancelled,
    OrderEvent.OrderShipped 
{
  UUID orderId();
  OrderState applyTo(OrderState current);

  record OrderPlaced(UUID orderId, String customerEmail) implements OrderEvent 
  {
    public OrderState applyTo(OrderState s) 
    {
      return OrderState.initial(orderId, customerEmail);
    }
  }
  // ... other event types
}

Using a sealed interface means the compiler enforces exhaustiveness in switchexpressions. Adding a new event type without handling it is a compile error, not a runtime surprise.

Each event carries only the data it needs and knows how to apply itself to the current state via applyTo(OrderState). This is the self-describing event pattern.

The Fold (Event Replay)

A fold, also known as left reduction, is the process of reconstructing state from a list of events over the event stream:

// EventProjection.java
public OrderState replayEvents(List<OrderEvent> events) 
{
  return events.stream()
    .reduce(OrderState.empty(), this::apply, (a, b) -> b);
}

private OrderState apply(OrderState state, OrderEvent event) 
{
  return event.applyTo(state);
}

OrderState.empty() is the identity element or the seed. Each event is a step function that transforms one immutable state into the next. This is pure functional programming: no side effects, no shared mutable state, entirely deterministic and testable in isolation.

Commands as Sealed Records

Commands are sealed records grouped in a container interface:

public sealed interface Command permits Command.PlaceOrderCommand, 
  Command.AddItemCommand,Command.ShipOrderCommand, Command.CancelOrderCommand 
{
  record PlaceOrderCommand(String customerEmail) implements Command {}
  record AddItemCommand(UUID orderId, String productName,
    int quantity, BigDecimal price) implements Command {}
// ...
}

\Sealed records give commands value semantics (equality by content, toString for free. and type safety (exhaustive pattern matching in the handler).

Command Results as Sealed Types

CommandResult is a sealed interface expressing all possible outcomes without exceptions:

public sealed interface CommandResult permits CommandResult.Success,
  CommandResult.InvalidState, CommandResult.NotFound,
  CommandResult.ValidationError 
{
  record Success(UUID aggregateId) implements CommandResult {}
  record InvalidState(String message) implements CommandResult {}
  record NotFound(String message) implements CommandResult {}
  record ValidationError(String message) implements CommandResult {}
}

The caller can switch on the result exhaustively. There are no checked exceptions, no nullable returns, and the type system documents all possible failure modes.

The Event Store

EventStore is the write-side infrastructure. It does two things atomically:

Persists the event to EVENT_STORE (JPA via EventRepository).
Publishes the event to the Spring application event bus.

public void append(UUID aggregateId, String aggregateType, OrderEvent event) 
{
  int version = nextVersion(aggregateId);
  String json = objectMapper.writeValueAsString(event);
  StoredEvent entity = new StoredEvent(aggregateId, aggregateType,
    version, eventType, json);
  eventRepository.save(entity);
  applicationEventPublisher.publishEvent(event);
}

Versioning provides a lightweight optimistic concurrency guard by preventing concurrent writes from corrupting the stream, based on the unique value aggregateId + version.

The Read-Side Projection

OrderProjection is a Spring component that listens for domain events and updates the read model:

@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void on(OrderEvent event) 
{
  OrderReadModel model = orderRepository.findByOrderId(event.orderId())
    .orElse(new OrderReadModel());
  // update fields from event ...
  orderRepository.save(model);
}

@TransactionalEventListener(phase = AFTER_COMMIT) ensures the read model is only updated after the event store transaction commits successfully, preventing this way phantom updates if the write-side transaction rolls back.

Running the Application

Prerequisites: Java 21, Maven, Docker (for PostgreSQL via TestContainers in tests).

# Build and run all tests (requires Docker)
./mvnw clean package

# Run the application (requires a running PostgreSQL instance)
./mvnw spring-boot:run

# Skip tests
./mvnw clean package -DskipTests

API Reference

Method	Path	Description
POST	`/orders`	Place a new order
POST	`/orders/{id}/items`	Add an item to an order
POST	`/orders/{id}/ship`	Ship an order
POST	`/orders/{id}/cancel`	Cancel an order
GET	`/orders/{id}`	Reconstruct current state from events
GET	`/orders/{id}/events`	Retrieve the full event stream
GET	`/orders/{id}/read-model`	Retrieve the denormalized read model

Place an order:

Add an item:

POST /orders/{id}/items
{ "productName": "Widget", "quantity": 3, "price": 9.99 }

Ship an order:

POST /orders/{id}/ship
{ "trackingNumber": "TRACK-001" }

Opinions expressed by DZone contributors are their own.

Generated by Readability.php.

Detecting Bugs and Vulnerabilities in Java With SonarQube

Ramya vani Rayala — Wed, 20 May 2026 18:00:00 GMT

Detect Bugs and Vulnerabilities in Java With SonarQube

The security audit report landed unexpectedly. It highlighted a critical vulnerability in our payment processing module. We had passed all unit tests. We had passed all integration tests. The code review looked clean. Yet the auditors found a hardcoded API key hidden in a utility class. This key allowed access to our third-party payment gateway. Anyone with access to the repository could see it. We were lucky the auditors found it before a malicious actor did. This incident was a wake-up call. We realized manual code reviews were not enough. We needed automated static analysis. We needed SonarQube.

In this article, I will share how we integrated SonarQube into our Java development workflow. I will explain the specific rules that exposed our vulnerabilities. I will detail how we configured quality gates to prevent future regressions. This is not a generic installation guide. It is a record of how we shifted security left in our pipeline. Static analysis is not just about finding bugs. It is about building a culture of quality.

The Blind Spot in Our Testing

Our testing strategy relied heavily on functional correctness. We wrote tests to ensure features worked as expected. We did not write tests to ensure secrets were absent. We did not write tests to check for SQL injection patterns. These security concerns fell outside the scope of standard unit testing. Developers focused on delivering features quickly. Security was an afterthought. This mindset created technical debt. It also created risk.

The hardcoded key incident showed us the gap. The developer who wrote the code intended to replace the key later. They forgot. The code merged to the main branch. It reached production. We rotated the key immediately, but the exposure window was dangerous. We needed a safety net. We needed a tool that could scan every commit for these patterns. SonarQube offered this capability.

Integrating SonarQube into CI/CD

We chose to integrate SonarQube into our Jenkins pipeline. This ensured every build was analyzed. We did not want developers to run the scan manually. Manual steps get skipped. Automation enforces consistency. We added a stage to our Jenkinsfile specifically for static analysis.

This configuration triggered the Maven Sonar plugin. It sent code metrics to the SonarQube server. The server analyzed the code against a set of rules. These rules covered bugs and vulnerabilities, and code smells. The analysis happened in parallel with our tests. It added minimal time to the build. The results were available immediately after deployment.

The Rule That Caught Us

SonarQube has thousands of rules. We did not enable all of them initially. We started with the Sonar Way profile. This profile includes a curated set of essential rules. One specific rule flagged our hardcoded credential issue. The rule key is java:S2068. It searches for strings that look like passwords or keys.

Here is the code that triggered the alert.

SonarQube marked this line as a critical vulnerability. It recognized the pattern of a secret key. It suggested moving the value to an environment variable. This feedback was immediate. The developer saw the issue in the pull request dashboard. They fixed it before merging. This prevented the vulnerability from reaching production.

Configuring Quality Gates

Finding issues is only half the battle. You must prevent bad code from merging. We configured quality gates in SonarQube. A quality gate defines the conditions for a build to pass. We set strict thresholds for our main branch.

New bugs: Must be zero.
New vulnerabilities: Must be zero.
New security hotspots: Must be reviewed.
Code coverage: Must be above 80 percent.

If a pull request failed these conditions, the pipeline failed. This gave us leverage. We could tell developers they could not merge until the issues were resolved. It enforced accountability. It also prevented technical debt from accumulating. We treated security violations like compilation errors. They blocked progress until fixed.

Handling False Positives

No tool is perfect. SonarQube sometimes flags safe code as risky. We encountered this with utility methods that handled strings resembling passwords. The tool raised alarms unnecessarily. This creates noise. Noise leads to alert fatigue. Developers start ignoring the warnings.

We learned to tune the rules. We marked specific issues as false positives in the dashboard. We added comments to the code to explain why the pattern was safe.

This annotation told SonarQube to ignore the rule for this line. We used this sparingly. We required a justification for every suppression. This ensured we did not hide real vulnerabilities. We reviewed suppressions during code review. This kept the process honest.

Security Hotspots vs. Vulnerabilities

SonarQube distinguishes between vulnerabilities and security hotspots. Vulnerabilities are confirmed issues. Hotspots are code that needs manual review. This distinction is important. Not every risky pattern is a bug. Some patterns require context to evaluate.

We established a process for reviewing hotspots. A senior engineer reviewed each hotspot. They determined if it was a real risk. If it were, they converted it to a vulnerability. If not, they marked it as Safe. This human-in-the-loop approach reduced false positives. It also educated developers on security patterns. They learned why certain code was risky. This improved overall code quality over time.

Lessons Learned and Best Practices

Our journey with SonarQube taught us several lessons. We incorporated these into our development standards.

Fail fast: Run analysis on every commit. Do not wait for nightly builds. Immediate feedback helps developers fix issues while context is fresh.
Start small: Do not enable all rules at once. Start with the critical security rules. Add more rules gradually. This prevents overwhelming the team.
Fix the root cause: Do not just suppress warnings. Understand why the rule exists. Fix the underlying code pattern. This prevents similar issues elsewhere.
Track trends: Monitor the technical debt ratio over time. It should decrease. If it increases, investigate why. Are we rushing features? Are we skipping reviews?
Educate the team: Tools do not replace knowledge. Hold sessions on secure coding practices. Explain the SonarQube rules. Help developers understand the why behind the rules.
Integrate with IDE: Install the SonarLint plugin in IntelliJ or Eclipse. This brings analysis to the developer workstation. They see issues before committing code. This is the fastest feedback loop.
Secure the server: SonarQube itself holds sensitive data. Secure the server with authentication. Restrict access to project settings. Rotate admin passwords regularly. Do not expose the dashboard to the public internet.

Conclusion

Integrating SonarQube transformed our approach to Java development. We moved from reactive security to proactive quality assurance. The hardcoded key incident never happened again. The tool caught similar patterns early in the cycle. Developers became more aware of security implications. They wrote cleaner code. They respected the quality gates.

Static analysis is not a silver bullet. It does not catch logic errors or business rule violations. It does not replace penetration testing. However, it is a powerful layer in a defense-in-depth strategy. It catches the low-hanging fruit automatically. This frees up security engineers to focus on complex threats.

We continue to refine our rules and thresholds. We add custom rules for our specific domain logic. We treat the SonarQube dashboard as a health monitor for our codebase. It tells us when our code is getting sick. We treat it before the patient crashes. Java provides a robust ecosystem for building secure applications. SonarQube helps us uphold that standard. Happy coding and keep your code clean.

Opinions expressed by DZone contributors are their own.

Generated by Readability.php.

Introduction to Tactical DDD With Java: Steps to Build Semantic Code

Otavio Santana — Wed, 20 May 2026 15:30:00 GMT

Steps to Build Semantic Code

Modern software systems rarely fail due to poor coding skills. Most failures occur when teams lose sight of the business problem they are addressing. As systems evolve, requirements shift, teams expand, and new integrations are added, codebases often become collections of technical decisions that lack business context. Classes become generic managers and services, methods devolve into procedural scripts, and communication between developers and domain experts diminishes. Tactical Domain-Driven Design (DDD) addresses this issue by emphasizing software that directly reflects business language in code, rather than focusing solely on infrastructure or frameworks.

The term “semantic” comes from the Greek semantikos, meaning “significant” or “meaningful,” which is central to Tactical DDD. The objective is not just to reorganize classes, but to ensure code communicates intent clearly to both engineers and business experts. In modern Java systems, where complexity increases due to distributed architectures, integrations, and ongoing business changes, this clarity is essential for long-term maintainability.

Tactical DDD provides practical patterns, such as entities, value objects, aggregates, repositories, factories, and domain services, to preserve codebase meaning and manage complexity. This article will examine these patterns step by step using Java and a soccer championship scenario to show how semantic code improves system understanding, evolution, and maintenance.

Entity

Before applying Tactical DDD patterns, it is important to recognize that they should not be the starting point of the design process. A common mistake in software projects is to begin with entities, repositories, and aggregates without first understanding the business. Tactical patterns serve as implementation tools, not discovery tools. Strategic DDD should begin with defining domain boundaries, the ubiquitous language, and the business context. Only after clarifying the problem space should you translate that understanding into code using tactical patterns.

An Entity is a core Tactical DDD pattern. The term originates from the Latin ens, meaning “being” or “existing thing.” In software design, it refers to maintaining its identity throughout its lifecycle. An entity is defined not by its current attributes, but by the business’s recognition of it as the same conceptual object over time. Entities are useful when the domain must track the lifecycle of something important to the business.

In a soccer championship, a player is a clear example of an entity. A player may change teams, positions, salary, or statistics during a career, but the system continues to recognize the player as the same individual within the domain. Therefore, identity is more important than changes to attributes. The following Java class illustrates this concept:

import java.util.UUID;

public class Player {

    private UUID id;

    private String name;

    private Position position;

    public Player(UUID id, String name, Position position) {
        this.id = id;
        this.name = name;
        this.position = position;
    }
}

The Player class demonstrates the Entity pattern by using a unique identifier in the id field. This identifier enables the application to distinguish one player from another, regardless of changes to other attributes. While name and position may change, the identity remains constant. This characteristic defines the object as an entity rather than a simple data structure or value object.

Value Object

Entities are defined by identity, but not all domain concepts require lifecycle tracking or unique identification. Many business concepts describe characteristics, measurements, classifications, or immutable meanings. The Value Object pattern addresses these cases. Here, “value” means the object is defined solely by its attributes, not by identity. In Tactical DDD, value objects reduce the need for primitives and clarify the domain language within the codebase.

A Value Object is an immutable object that represents a descriptive aspect of the domain. Unlike entities, two value objects with identical values are considered the same. Value objects are often used for concepts such as money, addresses, coordinates, statuses, measurements, or classifications. Their primary purpose is to improve semantic clarity and encapsulate domain rules for specific concepts.

In a soccer championship scenario, player position is a good example of a value object because the application does not need to track its lifecycle. The domain is concerned only with the meaning of the value. The following Java enum illustrates this concept:

public enum Position {
    GOALKEEPER,
    DEFENDER,
    MIDFIELDER,
    FORWARD
}

The Position enum applies the Value Object pattern by representing a business classification rather than using primitive strings throughout the codebase. By using explicit types instead of raw text, such as "forward" or "goalkeeper", the application improves readability, reduces invalid states, and reinforces a shared language between developers and domain experts.

Factory

As domain models evolve, object creation often requires more than calling a constructor. Business rules, validations, default values, and initialization steps may spread into controllers, services, or application layers, leading to duplication and fragmented domain knowledge. The Factory pattern centralizes object creation, ensuring new domain objects are valid and meaningful.

A Factory is a Tactical DDD pattern that encapsulates the creation logic of entities or aggregates. Its purpose is not just to “hide the constructor,” but to express domain intent during object creation. Originating from manufacturing, factories ensure objects are assembled correctly before use. In software, this approach maintains consistency and enforces business rules during instantiation.

In a soccer championship scenario, creating a player requires more than allocating memory. A new forward player must have the correct position and a unique identity. Centralizing this logic in a factory prevents duplication across the system.

import java.util.UUID;

public class PlayerFactory {

    public Player createFoward(String name) {
        return new Player(
                UUID.randomUUID(),
                name,
                Position.FORWARD
        );
    }
}

PlayerFactory implements the Factory pattern by encapsulating the details of Player creation. The application layer does not need to manage identifier generation or position assignment for a forward player. The method name communicates business intent, allowing the code to express a meaningful domain operation rather than low-level construction details.

Aggregate Root

As systems scale, maintaining consistency between related entities becomes more challenging. Without clear boundaries, business rules can spread across services, repositories, and transactions. Tactical DDD addresses this by defining explicit consistency boundaries within the domain model. Aggregate and Aggregate Root patterns are essential to this approach.

An Aggregate is a group of related entities and value objects managed as a single consistency boundary. The Aggregate Root serves as the main entry point, coordinating and protecting the aggregate’s internal state. In practice, the aggregate root ensures controlled modifications and maintains business rule consistency during state changes.

In a soccer championship scenario, a team acts as an aggregate root by managing the lifecycle and consistency of its players. The application should not modify the player collection directly; all changes should occur through the team’s defined behaviors:

import java.util.Collections;
import java.util.List;

public class Team {

    private TeamId id;

    private String name;

    private List<Player> players;

    public Team(TeamId id, String name, List<Player> players) {
        this.id = id;
        this.name = name;
        this.players = players;
    }

    public List<Player> getPlayers() {
        return Collections.unmodifiableList(players);
    }

    public void remove(Player player) {
        players.remove(player);
    }

    public void add(Player player) {
        players.add(player);
    }
}

The Team class implements the Aggregate Root pattern, managing access to its player collection. Rather than allowing direct modification, it has add and remove. This method enables business rules to evolve and ensures consistency across the application. The aggregate root safeguards the domain boundary and maintains the cycle.

Repository

One of the biggest challenges in enterprise applications is avoiding tight coupling between business logic and persistence concerns. Over time, SQL queries, database operations, caching logic, and infrastructure details can start leaking into the domain layer, making the code harder to maintain and evolve. Tactical DDD addresses this problem with the Repository pattern, which provides a collection-like abstraction for managing aggregates.

The term “repository” originates from the Latin repositorium, meaning “a place where things are stored.” In Domain-Driven Design, a repository is not merely a DAO or a utility class for executing queries. Its primary goal is to provide access to aggregates while hiding infrastructure complexity from the domain model. A repository allows the application to work with domain concepts instead of persistence mechanisms, preserving the separation between business logic and technical implementation.

In the soccer championship scenario, the application needs a mechanism to persist and retrieve teams without exposing database details to the business flow. Since Team acts as the aggregate root, the repository is responsible for managing it as a consistency boundary:

public interface TeamRepository {

    Team save(Team team);
}

The TeamRepository applies the Repository pattern by abstracting persistence operations behind a domain-oriented contract. The application layer does not need to know whether the data is stored in PostgreSQL, MongoDB, Redis, or another technology. More importantly, the repository communicates the business intention directly through the aggregate itself. Instead of manipulating tables or records, the code works with meaningful domain concepts such as Team, preserving the semantic clarity of the model and reducing coupling between the domain and infrastructure layers.

Domain Service

Not every business operation fits within an entity or aggregate root. As the domain evolves, some rules involve multiple entities or coordination logic that do not belong to a single object. Assigning these responsibilities to entities can lead to bloated models and reduced cohesion. Tactical DDD addresses this with the Domain Service pattern.

A Domain Service contains business logic that does not belong to a specific entity or value object, but remains part of the domain model. Its role is to execute meaningful business operations involving multiple domain objects, not to handle technical orchestration or infrastructure. In DDD, a service encapsulates domain behavior across aggregates while maintaining the model’s clarity.

In the soccer championship scenario, transferring a player between teams is a business operation involving multiple aggregates. The responsibility does not belong exclusively to the player or to a single team. Instead, the operation represents a domain action coordinating both source and destination teams:

public class TransferService {

    public void transfer(
            Player player,
            Team source,
            Team destination) {

        source.remove(player);
        destination.add(player);
    }
}

TransferService implements the Domain Service pattern by encapsulating the business logic for transferring a player between teams. This service expresses the domain concept directly, rather than spreading logic across controllers or application layers. The method communicates business intent clearly using the domain’s ubiquitous language. Instead of exposing low-level details, the code now reflects a meaningful operation recognized by both developers and business experts: transferring a player during the championship lifecycle.

Domain Event

In complex systems, important business actions rarely affect only a single part of the application. A change in one domain often triggers reactions in other contexts, such as notifications, analytics, integrations, auditing, or external workflows. Directly coupling these concerns creates rigid architectures in which every new requirement increases dependencies across the system. Tactical DDD addresses this challenge with the Domain Event pattern.

A Domain Event represents an important event that has already occurred within the business domain. The emphasis on the past tense is intentional because events describe facts, not commands or intentions. The term “event” originates from the Latin eventus, meaning “outcome” or “occurrence.” In Domain-Driven Design, domain events allow systems to communicate meaningful business changes while reducing coupling between components and bounded contexts. Instead of directly invoking every dependent operation, the domain publishes events that other parts of the system may react to independently.

In the soccer championship scenario, hiring a new player is an important business occurrence that other parts of the system may care about. The championship may want to notify fans, update statistics, trigger merchandising actions, or synchronize with external systems. Instead of embedding all these responsibilities directly into the transfer logic, the application can represent the occurrence explicitly through a domain event:

public record NewSoccerHired(
        Team team,
        Player player) {
}

The event can then be published once the business operation finishes successfully:

eventPublisher.publish(
        new NewSoccerHired(destination, player)
);

The NewSoccerHired record applies the Domain Event pattern by representing a meaningful business fact inside the domain model. Instead of tightly coupling multiple responsibilities, the system now exposes a semantic business occurrence that other parts of the architecture can react to independently. This approach improves extensibility, reduces direct dependencies, and preserves the ubiquitous language across the application lifecycle.

Application Service

As systems evolve, business operations often require coordination across domain components, persistence, and integration points. Without a clear orchestration layer, this logic may spread across controllers, APIs, and infrastructure classes, resulting in tightly coupled, hard-to-maintain applications. Tactical DDD addresses this with the Application Service pattern.

An Application Service orchestrates use cases and coordinates domain operations. Unlike domain services, which encapsulate business rules, an application service manages the execution flow of business actions. In DDD, it serves as the coordination layer, connecting repositories, domain operations, and external interactions, while keeping the domain model focused on business behavior.

In a soccer championship scenario, transferring a player between teams requires more than one business rule. This operation coordinates transfer logic, persistence, and event publication. The following class centralizes this orchestration in a single use case:

public class TransferPlayerUserCase {

    private final TeamRepository teamRepository;
    private final TransferService transferService;
    private final EventPublisher eventPublisher;

    public TransferPlayerUserCase(
            TeamRepository teamRepository,
            TransferService transferService,
            EventPublisher eventPublisher) {
        this.teamRepository = teamRepository;
        this.transferService = transferService;
        this.eventPublisher = eventPublisher;
    }

    public void execute(
            Player player,
            Team source,
            Team destination) {

        transferService.transfer(player, source, destination);

        teamRepository.save(source);
        teamRepository.save(destination);

        eventPublisher.publish(
                new NewSoccerHired(destination, player)
        );
    }
}

The TransferPlayerUserCase demonstrates the Application Service pattern by orchestrating the entire player transfer process. Rather than placing orchestration logic in controllers or entities, this class coordinates domain operations, persistence, and event publication within a single workflow. The method represents a meaningful business action within the domain: transferring a player between teams during the championship.

Conclusion

Tactical Domain-Driven Design does not aim to add unnecessary complexity or apply patterns indiscriminately. Its purpose is to help engineers build software that clearly communicates business meaning through code. By introducing concepts such as entities, value objects, factories, aggregates, repositories, domain services, domain events, and application services, developers create systems that are easier to understand, maintain, and adapt as business needs evolve. Tactical DDD also bridges the gap between technical and business perspectives, making code a semantic representation of the domain.

This article introduces core Tactical DDD patterns using Java and a soccer championship scenario. The aim is not to cover every aspect of Domain-Driven Design, but to show how these patterns help build expressive and maintainable systems. As projects become more complex, preserving business meaning within the codebase is increasingly important, especially in modern distributed architectures where technical complexity can obscure domain language.

Opinions expressed by DZone contributors are their own.

Generated by Readability.php.

AI Agents in Java: Architecting Intelligent Health Data Systems

Ramya vani Rayala — Wed, 20 May 2026 15:00:00 GMT

Designing Intelligent Health Data Systems

Likes (0)

Join the DZone community and get the full member experience.

Executive Summary

Modern health data analytics increasingly leverage AI agent software components that process information and make decisions, often using large language models (LLMs) or machine learning models. In Java, you can build agentic systems using libraries like DJL (Deep Java Library), Spring AI, or by integrating LLM APIs. This document includes Maven setup, minimal Spring Boot code (controllers and services), a simple agent example, diagrams, and a comparison of different agent approaches.

Flowchart

Maven Dependencies

Define the necessary dependencies in pom.xml (Spring Web, Validation, DJL, OpenAI SDK, etc.):

<dependencies>

  <!-- Spring Boot Web for API -->
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
  </dependency>

  <!-- Validation (optional) -->
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-validation</artifactId>
  </dependency>

  <!-- OpenAI Java SDK (LLM API) -->
  <dependency>
    <groupId>com.openai</groupId>
    <artifactId>openai-java</artifactId>
    <version>4.0.0</version>
  </dependency>

  <!-- DJL for local ML inference -->
  <dependency>
    <groupId>ai.djl</groupId>
    <artifactId>api</artifactId>
    <version>0.36.0</version>
  </dependency>

  <dependency>
    <groupId>ai.djl.mxnet</groupId>
    <artifactId>mxnet-engine</artifactId>
    <version>0.36.0</version>
  </dependency>

  <!-- (Optional) Spring AI -->
  <dependency>
    <groupId>org.springframework.experimental</groupId>
    <artifactId>spring-boot-starter-ai</artifactId>
    <version>0.0.1</version>
  </dependency>

</dependencies>

This setup assumes you will use the OpenAI Java SDK and DJL. Replace the spring-boot-starter-ai version with the latest as needed.

1. Domain Model & Configuration

Define simple data classes for health analysis requests and responses in com.example.health:

package com.example.health;

public record VitalSigns(
    double temperature,
    double bloodPressure,
    int heartRate
) {}

This example record holds patient vitals. You can also add a Spring @Configuration if needed, for example, to configure the DJL engine:

package com.example.config;

import org.springframework.context.annotation.Configuration;
import ai.djl.Engine;

@Configuration
public class DjLConfig {

    public DjLConfig() {
        Engine.getEngine("MXNet");
    }
}

No special configuration is required for OpenAI; it reads API keys from the OPENAI_API_KEY environment variable.

2. Service Layer / Agent Component

Implement a service that acts as your “agent.” It can use a local DJL model or call an external LLM API:

package com.example.agent;

import com.openai.client.OpenAIClient;
import com.openai.client.okhttp.OpenAIOkHttpClient;
import com.openai.models.responses.Response;
import com.openai.models.responses.ResponseCreateParams;
import org.springframework.stereotype.Service;

@Service
public class HealthAgent {

    private final OpenAIClient openAiClient;

    public HealthAgent() {
        this.openAiClient = OpenAIOkHttpClient.fromEnv();
    }

    public String analyzeVitals(String patientId, VitalSigns vitals) {
        String prompt = String.format(
            "Patient %s has temperature %.1f°C, blood pressure %.0f/%d, heart rate %d. Suggest the next diagnostic step.",
            patientId, vitals.temperature(), vitals.bloodPressure(), vitals.bloodPressure(), vitals.heartRate()
        );

        ResponseCreateParams params = ResponseCreateParams.builder()
                .model("health")
                .input(prompt)
                .build();

        Response response = openAiClient.responses().create(params);
        return response.outputText();
    }
}

This HealthAgent service builds a prompt from VitalSigns and uses the OpenAI Java SDK to call the LLM.

3. REST Controller

Expose an HTTP API to trigger the agent:

package com.example.api;

import com.example.agent.HealthAgent;
import com.example.health.VitalSigns;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.*;

@RestController
@RequestMapping("/api/health")
public class HealthController {

    private final HealthAgent agent;

    public HealthController(HealthAgent agent) {
        this.agent = agent;
    }

    @PostMapping("/analyze")
    public ResponseEntity<String> analyze(
            @RequestParam String patientId,
            @RequestBody VitalSigns vitals) {

        String result = agent.analyzeVitals(patientId, vitals);
        return ResponseEntity.ok(result);
    }
}

This controller maps POST /api/health/analyze?patientId=XYZ with a JSON body containing VitalSigns. It delegates to the HealthAgent and returns the response.

4. Agent Patterns and Architecture

AI “agents” can follow different patterns. Spring AI documentation distinguishes workflows from fully agentic systems that act autonomously. In healthcare, predictable workflows are often preferred for safety, although LLM-based agents can be dynamic.

Common agent patterns include:

Chaining: Multi-step reasoning
Parallelization: Running tasks in parallel and combining results
Routing: Directing inputs to specialized prompts or tools
Looping: Iterating until a goal is achieved

Spring AI provides abstractions to implement these patterns. For example, a chain workflow may sequentially call ChatClient.prompt(...).call() while passing outputs between steps.

The example above is a single-step LLM call, but the architecture can be expanded:

Clients → Spring Boot API → Agent (Spring AI or custom logic) → LLM/model → API response

5. Table: Agent Approaches

Approach	Pros	Cons	Use Cases
Custom Java Logic	Fully controllable code no external calls	Limited intelligence no learning or language understanding	Simple rule-based analysis strict data privacy requirements
DJL	Runs on JVM, GPU support full control of model and data	Heavy dependency must train/download models resource-intensive	On-premises analytics private data processing when a fixed ML model suffices
LLM API (OpenAI, etc.)	State-of-art language understanding managed by provider	Latency, cost, and data privacy concerns requires API key	NLP-heavy tasks prototyping and research
Spring AI Patterns	High-level workflows (chain, parallel, routing) built-in integrates with Spring	Underlying calls are still to models/APIs complexity overhead	Enterprise applications needing structured LLM agents, combining LLM with Spring ecosystem

6. Implementation Timeline

2026-02-01: Project kickoff (set up Spring Boot)
2026-02-03: Define domain models (VitalSigns, etc.)
2026-02-05: Configure dependencies (DJL, OpenAI SDK)
2026-02-07: Implement HealthAgent service (LLM call)
2026-02-10: Add REST controller and test endpoint
2026-02-12: Optional: integrate DJL model (local inference)
2026-02-14: Add error handling and validation
2026-02-15: Final testing and local deployment

7. Running Locally

Set your API key:

Ensure OPENAI_API_KEY is set as an environment variable.

Build and run (using Maven):

By default, the app runs on http://localhost:8080.

Test the API:

curl -X POST "http://localhost:8080/api/health/analyze?patientId=123" \
     -H "Content-Type: application/json" \
     -d '{"temperature": 38.5, "bloodPressure": 130, "heartRate": 95}'

You should see the AI agent’s response as plain text.

8. Assumptions

Java Version: Java 17 (no license restrictions assumed)
External Services: OpenAI or other LLM APIs require network access and valid API keys
Data Privacy: Health data must be handled securely (e.g., encryption, HIPAA compliance)
Machine Learning: DJL uses MXNet by default; GPU acceleration requires proper setup
Architecture: Kafka, WebSockets, or databases are omitted for brevity

Conclusion

This document outlines how to integrate AI agents into a Spring Boot Java application. Key takeaways:

Project Setup: Use Spring Boot for REST APIs with ML/LLM dependencies
Agent Logic: Implement services that call LLM APIs or local ML models
Patterns: Use structured agent patterns for complex workflows
Trade-offs: Choose between custom logic, local ML, or LLM APIs based on requirements

AI Health (Apple) Java (programming language) systems

Opinions expressed by DZone contributors are their own.

Generated by Readability.php.

Ujorm3: A New Lightweight ORM for JavaBeans and Records

Pavel Ponec — Tue, 19 May 2026 18:00:00 GMT

Attention Required! | Cloudflare

Please enable cookies.

You are unable to access dzone.com

You are unable to access dzone.com

Why have I been blocked?

What can I do to resolve this?

You can email the site owner to let them know you were blocked. Please include what you were doing when this page came up and the Cloudflare Ray ID found at the bottom of this page.

Cloudflare Ray ID: 9f3f833dbb6fd40f • Your IP: 5.1.64.146 • Performance & security by Cloudflare

Generated by Readability.php.