Java Code Geeks

When Services Wait Forever: A Practical Guide to Distributed Deadlocks

Eleftheria Drosopoulou — Fri, 10 Jul 2026 15:50:00 +0000

When Services Wait Forever: A Practical Guide to Distributed Deadlocks

Most developers have encountered a deadlock at least once. Two threads grab two locks in a different order. Suddenly, neither thread can continue. The application hangs, a thread dump reveals the culprit, and the problem is eventually fixed.

Distributed deadlocks are a very different beast. They don’t happen inside a single process. They don’t appear neatly inside a thread dump. In many cases, they don’t even involve traditional locks. Instead, they emerge from a web of interactions between services, databases, message queues, distributed caches, and external APIs.

The result is often far more expensive than a local deadlock. Requests start timing out. Retry storms appear. Queue lengths grow. Databases show increased lock contention. Yet every individual component looks healthy when viewed in isolation.

That’s what makes distributed deadlocks particularly dangerous: the problem exists between systems rather than within them.

In this article, we’ll examine how distributed deadlocks form, why traditional detection techniques break down at network scale, and which architectural patterns can prevent them from occurring in the first place.

What Is a Distributed Deadlock?

A deadlock occurs when multiple participants wait on each other in a circular dependency.

In traditional systems, the classic example involves two threads:

Thread A holds Lock 1 and waits for Lock 2.
Thread B holds Lock 2 and waits for Lock 1.

Neither thread can proceed.

In distributed systems, the principle is identical, but the resources become much more diverse.

The waiting relationship may involve:

Database row locks
Distributed locks
Service-to-service calls
Workflow reservations
Queue consumers
Rate-limiter tokens
Cache ownership
External APIs

Distributed deadlocks are commonly represented using a Wait-For Graph, where nodes represent processes or transactions and edges represent dependency relationships. If a cycle exists inside the graph, a deadlock exists.

The theory sounds simple. Production reality is not.

How Resource Cycles Form Across Services

Many engineers assume deadlocks only occur at the database layer. In distributed architectures, that’s rarely true.

Imagine an e-commerce platform with three core services:

Orders Service
Inventory Service
Payments Service

A customer places an order.

The Orders Service reserves an order record and calls Inventory. Inventory reserves stock and calls Payments.

Meanwhile, Payments needs additional customer data and calls Orders. The dependency chain now looks like this:

Orders
   waits for
Inventory

Inventory
   waits for
Payments

Payments
   waits for
Orders

A cycle has formed. Nobody is technically broken.

Nobody has crashed. Every service is simply waiting. Forever.

This exact pattern is why distributed deadlocks are often described as resource cycles spanning multiple trust boundaries. The circular wait condition remains the same as a traditional deadlock, but it now crosses processes, databases, and network boundaries.

Figure 1: Distributed Deadlock Cycle


+-----------+
|  Orders   |
+-----------+
      |
      v
+-----------+
| Inventory |
+-----------+
      |
      v
+-----------+
| Payments  |
+-----------+
      |
      |
      +-------------+
                    |
                    v

                 Orders

Figure 1. A distributed wait cycle spanning multiple services. No individual service is necessarily malfunctioning. The deadlock emerges from the dependency chain itself.

Why Traditional Deadlock Detection Fails

The reason local deadlocks are relatively easy to detect is because all information exists in one place. The operating system, database engine, or JVM can observe every lock holder and every waiting thread.

Distributed systems lose that luxury.

Service A only sees Service A.

Service B only sees Service B.

Database C only sees Database C.

No single component naturally possesses the entire dependency graph.

Traditional wait-for-graph algorithms rely on maintaining a global view of resource ownership and waiting relationships. While this approach works reasonably well in centralized environments, distributed systems require information gathering from multiple nodes and services before a complete graph can even be constructed.

Consequently, deadlock detection becomes significantly more expensive and less reliable.

The Visibility Problem

Perhaps the most frustrating aspect of distributed deadlocks is observability. Imagine a production incident.

You examine:

CPU usage
Memory utilization
Database health
Service metrics

Everything looks normal. Requests are stuck, but infrastructure appears healthy. This happens because a deadlock is fundamentally a coordination problem rather than a resource exhaustion problem.

The waiting relationships may be distributed across:

Five microservices
Three databases
Multiple availability zones

No dashboard automatically reconstructs the complete dependency cycle for you.

Researchers and practitioners often rely on distributed wait-for graphs, timeout-based detection, or centralized coordination services because detecting cycles across multiple sites requires aggregating information that does not naturally exist in one location.

A Realistic Example From Modern Architectures

Let’s consider a banking platform.

A transfer workflow performs three steps:

Reserve funds.
Allocate fraud-analysis resources.
Update account balances.

Now imagine another workflow executing simultaneously:

Allocate fraud-analysis resources.
Reserve funds.
Update account balances.

Both workflows eventually need the same resources. However, they acquire them in different orders.

Suddenly

Transfer Workflow A
  holds Funds Lock
  waits for Fraud Lock

Transfer Workflow B
  holds Fraud Lock
  waits for Funds Lock

At a local level, this resembles a classic deadlock. At scale, those locks may live inside separate services, separate databases, or even separate regions. The complexity grows dramatically.

Architectural Patterns That Break the Cycle

The best distributed deadlock is the one that never occurs. Instead of relying on increasingly sophisticated detection algorithms, modern architectures typically focus on prevention.

1. Consistent Resource Ordering

One of the oldest and most effective strategies remains one of the best. Always acquire resources in the same order.

For example:

Customer
   ->
Account
   ->
Payment

Never allow another workflow to use:

Payment
   ->
Customer
   ->
Account

Consistent ordering prevents the circular wait condition from emerging in the first place.

2. Timeouts and Leases

Distributed resources should rarely be held indefinitely.

Instead of permanent ownership:

Lock expires after 30 seconds.
Reservation expires after 2 minutes.
Workflow automatically retries.

Timeout-based strategies cannot eliminate deadlocks entirely, but they significantly reduce how long systems remain stuck. Timeout-based detection is commonly used in distributed database environments where maintaining a complete global dependency graph is impractical.

3. Avoid Synchronous Dependency Chains

One of the most common microservice mistakes looks like this:

Service A
  ->
Service B
  ->
Service C
  ->
Service D

Every additional synchronous hop increases the probability of resource cycles. Event-driven communication often reduces these dependencies because services become less tightly coupled. Instead of waiting, services publish events and continue processing asynchronously.

Why Sagas Help

One of the biggest reasons the Saga Pattern became popular is that it reduces long-running distributed transactions. Traditional distributed transactions tend to hold resources while waiting for remote operations to complete.

Sagas approach the problem differently. Instead of locking everything until the entire workflow finishes, each step commits independently. If something fails later, compensating actions reverse the previous work.

For example:

Reserve Inventory
     ✓

Reserve Payment
      ✓

Shipping Failed
      ✗

Compensating Action:
Release Payment
Release Inventory

No long-running global lock needs to exist.

As a result, many opportunities for distributed deadlocks disappear.

Figure 2: Traditional Transaction vs Saga

Traditional Distributed Transaction	Saga-Based Workflow
Long-lived locks	Short-lived operations
High coordination cost	Lower coordination cost
Strong coupling	Looser coupling
Greater deadlock risk	Reduced deadlock risk
Difficult recovery	Compensation-based recovery

Design Principles for Deadlock-Resistant Systems

After several years of building distributed systems, one pattern becomes obvious:

The best teams don’t focus solely on deadlock detection.

They focus on deadlock avoidance.

That usually means adopting a few simple principles:

Keep critical sections short.
Avoid holding resources during network calls.
Use consistent resource ordering.
Prefer asynchronous communication when possible.
Use leases instead of permanent locks.
Design workflows around compensation rather than global transactions.
Continuously trace dependency chains between services.

These principles are far less expensive than implementing a sophisticated distributed deadlock detection system after production incidents start appearing.

Conclusion

Distributed deadlocks are harder than local deadlocks because the system that contains the problem is no longer visible from a single location.

The cycle may span databases, microservices, queues, caches, and external APIs. Every participant appears healthy, yet the system as a whole becomes stuck.

Traditional deadlock detection techniques rely on having a complete view of the dependency graph. In distributed environments, creating that view is often the hardest part of the problem.

For that reason, modern architectures increasingly prioritize prevention over detection. Consistent resource ordering, short-lived leases, asynchronous communication, and saga-based workflows all reduce the likelihood of circular waiting relationships forming in the first place.

Ultimately, distributed deadlocks are not merely a locking problem. They are an architectural problem. And architectural problems are far easier to prevent than they are to debug at 3 a.m.

What We Have Learned

Distributed deadlocks occur when circular waiting relationships form across services, databases, and other distributed resources. Unlike local deadlocks, they are difficult to detect because no single system naturally owns the complete dependency graph. Traditional wait-for-graph techniques become more complex at network scale, and observability tools often struggle to expose the root cause.

As a result, modern architectures increasingly emphasize prevention through resource ordering, leases, timeouts, asynchronous communication, and saga-based workflows rather than relying solely on detection mechanisms.

urther Reading

Tags

Jakarta EE 11 Under the Hood: What Spring Boot 4 Inherits and What It Ignores

Eleftheria Drosopoulou — Fri, 10 Jul 2026 05:31:00 +0000

Enterprise Java

Jakarta EE 11 Under the Hood: What Spring Boot 4 Inherits and What It Ignores

Spring Boot 4 has understandably grabbed most of the headlines in the Java ecosystem. However, underneath the excitement around Spring’s latest release lies another important story that many developers have largely missed: Spring Boot 4 arrives in a world where Jakarta EE 11 is now the enterprise Java baseline.

What’s particularly interesting is that Spring Boot 4 benefits from several Jakarta EE 11 improvements even when developers don’t realize it. At the same time, Spring continues to ignore certain Jakarta specifications because it already provides its own alternative abstractions.

Most teams upgrading Spring Boot applications will never explicitly add a Jakarta EE runtime. Nevertheless, many of the APIs, standards, and persistence capabilities they use every day have been influenced by the work happening inside the Jakarta EE platform.

So let’s look past the release notes and focus on the practical question:

What actually changed in Jakarta EE 11, and which of those changes matter to a Spring Boot developer writing everyday @Entity classes and business services?

Why Jakarta EE 11 Matters to Spring Developers

Historically, Spring and Jakarta EE were often portrayed as competing approaches to enterprise Java.

That distinction no longer tells the full story.

Modern Spring Boot applications depend heavily on Jakarta specifications. Every time a developer writes:

@Entity
@Table
@Embeddable
@NotNull

they are using Jakarta APIs.

The question is not whether Spring uses Jakarta EE.

It does.

The real question is which parts of Jakarta EE Spring adopts and which parts it decides to replace with its own programming model.

Jakarta EE 11 introduces one entirely new specification—Jakarta Data 1.0—while also updating core APIs including CDI 4.1, Validation 3.1, and Persistence 3.2. These updates collectively focus on improving developer productivity and modernizing enterprise Java for Java 17 and Java 21 environments.

Jakarta Data 1.0: The Standardized Version of a Familiar Idea

If there is one feature that generated the most buzz around Jakarta EE 11, it is undoubtedly Jakarta Data 1.0.

The funny thing is that Spring developers will immediately recognize it.

Jakarta Data introduces a repository-based programming model that looks remarkably similar to what developers have been doing with Spring Data JPA for years.

Instead of writing repetitive data-access boilerplate, developers define repository interfaces and allow the framework to generate implementations automatically. Jakarta Data also supports method-name query generation, pagination, CDI integration, validation integration, and multiple datastore types.

For example, Spring developers are already comfortable with patterns such as:


public interface CustomerRepository {
    Customer findByEmail(String email);
}

That style of development is essentially what Jakarta Data standardizes for the broader Jakarta ecosystem. [openliberty.io], [javacodegeeks.com]

Does Spring Boot 4 Benefit?

Not directly.

Spring already has Spring Data.

In fact, Spring Data remains significantly more mature and feature-rich than Jakarta Data today.

However, Jakarta Data is important because it finally gives enterprise Java a standardized repository abstraction rather than relying on vendor-specific implementations.

For Spring developers, Jakarta Data is less about replacing existing code and more about observing where the broader Java ecosystem is heading.

CDI 4.1: Cleaner Dependency Injection

Dependency injection is something Spring developers use constantly.

However, many developers forget that Jakarta EE has its own mature dependency injection framework called CDI (Contexts and Dependency Injection).

Jakarta EE 11 includes CDI 4.1, which continues the effort to modernize and simplify the programming model while improving maintainability and reducing historical complexity.

If you’re using Spring Boot, you probably write code like this:

@Service
public class PaymentService {
}

and inject dependencies using constructor injection.

Spring’s model remains separate from CDI.

As a result, although Spring Boot applications benefit from the general direction of Jakarta EE modernization, they do not suddenly switch to CDI containers.

This is a classic example of Spring acknowledging a Jakarta standard while still preferring its own implementation.

From a practical standpoint, most Spring developers will never feel the CDI 4.1 upgrade directly.

Yet the update remains important because it continues reducing the gap between Jakarta EE and Spring-based development styles.

Jakarta Validation 3.1: Better Support for Modern Java

This is where things start becoming very relevant to everyday Spring development.

Jakarta Validation 3.1 introduces better support for modern Java language features, including validation on Java Records.

If your application uses request DTOs like:

public record CustomerRequest(
    @NotBlank String firstName,
    @NotBlank String lastName,
    @Email String email
) {}

then Jakarta Validation is already working behind the scenes.

Spring Boot continues to rely heavily on Bean Validation APIs for request validation, DTO validation, and entity validation. Consequently, every improvement inside Jakarta Validation directly benefits Spring applications. [jakarta.ee], [newsroom.eclipse.org]

This is one of those upgrades that many teams will inherit without changing a single line of code.

And honestly, those are often the best upgrades.

Jakarta Persistence 3.2: The Upgrade Every Spring Developer Inherits

While Jakarta Data received the headlines, I would argue that Persistence 3.2 is actually the most important Jakarta EE 11 update for Spring teams.

The reason is simple:

Almost every Spring business application uses JPA.

Jakarta Persistence 3.2 introduces several quality-of-life improvements that make modern Java entities feel much more natural. Among the most notable additions are:

Support for Java Records as @Embeddable and @IdClass
Built-in mapping for java.time.Instant
Built-in mapping for java.time.Year
Further movement away from legacy Date, Timestamp, and Calendar APIs in favor of the modern java.time package [jakarta.ee]

Consider an older persistence model:

private Timestamp createdAt;

Modern applications increasingly prefer:

private Instant createdAt;

Jakarta Persistence 3.2 formally strengthens that modern approach. [jakarta.ee]

For developers building Spring Boot applications, this is probably the Jakarta EE 11 feature that will have the most immediate effect on everyday code.

What Spring Boot 4 Still Ignores

Despite adopting many Jakarta APIs, Spring Boot continues to maintain its own opinions.

And honestly, that is unlikely to change.

For example:

Jakarta Specification	Spring Preference
CDI	Spring IoC Container
Jakarta Data	Spring Data
Jakarta REST	Spring MVC / WebFlux
Jakarta Security	Spring Security

This isn’t necessarily a bad thing. Spring’s ecosystem is one of the reasons many teams choose Spring in the first place.

However, it does mean that developers should not assume every Jakarta innovation automatically becomes a first-class Spring feature.

Sometimes Spring adopts it. Sometimes Spring replaces it. Sometimes Spring simply ignores it because it already provides a stronger abstraction.

The Bigger Trend Few Developers Notice

The most interesting takeaway from Jakarta EE 11 isn’t a specific feature. It’s the direction. For years, Spring was viewed as the innovation layer and Jakarta EE as the standards layer.

That gap has narrowed considerably. Jakarta Data now standardizes repository patterns that Spring popularized. Persistence continues modernizing around Java 21-era development practices.

Validation better supports records. CDI keeps becoming lighter and more developer-friendly.

As a result, the distinction between “Spring-style development” and “Jakarta-style development” is becoming less dramatic than it was a decade ago.

Conclusion

If you’re upgrading to Spring Boot 4, it is worth paying attention to Jakarta EE 11 even if you never deploy to a Jakarta EE server.

Many of the improvements introduced in Jakarta Validation 3.1 and Persistence 3.2 will quietly improve your applications. Meanwhile, Jakarta Data offers a glimpse into how the wider Java ecosystem is standardizing repository-driven data access.

Will Jakarta Data replace Spring Data? Not anytime soon.

Will CDI replace Spring’s dependency injection model? Almost certainly not.

However, understanding these changes helps developers appreciate how much of the modern Spring experience is now built on top of Jakarta standards.

And that may be the biggest story of Jakarta EE 11: even when Spring chooses its own abstractions, it is increasingly standing on the foundation that Jakarta continues to modernize.

What We Have Learned

Jakarta EE 11 introduces several updates that directly or indirectly affect Spring Boot 4 applications. Jakarta Data 1.0 brings a standardized repository model similar to Spring Data, CDI 4.1 continues modernizing dependency injection, Validation 3.1 improves support for modern Java features such as records, and Persistence 3.2 delivers practical improvements for JPA-based applications through better support for Instant, Year, and record-based models.

Although Spring continues to favor its own abstractions in areas such as dependency injection, security, REST, and data access, many Spring applications will still benefit from Jakarta EE 11 improvements beneath the surface.

Why I’m Moving My Dev Setup Off the Cloud (And Back to Local)

Eleftheria Drosopoulou — Thu, 09 Jul 2026 14:20:06 +0000

Software Development

Why I’m Moving My Dev Setup Off the Cloud (And Back to Local)

Cloud development environments have become one of the hottest trends in modern software engineering. Open a browser, spin up a preconfigured workspace, connect to a repository, and start coding within minutes. Platforms such as GitHub Codespaces, Gitpod, and cloud-hosted IDEs promise consistency, onboarding simplicity, and environments that closely resemble production. For distributed teams, those benefits are undeniably attractive.

And yet, after spending a considerable amount of time working with cloud-based development environments, I’ve been moving back toward a local-first setup.

This isn’t an argument against the cloud. Quite the opposite. Cloud platforms remain essential for CI/CD pipelines, testing, deployments, and production workloads. However, I’ve started questioning whether every stage of development actually benefits from living remotely.

What surprised me most is that the answer increasingly seems to be “no.”

Introduction: The Current Trend of “Everything in the Cloud”

Over the past few years, software teams have pushed aggressively toward cloud-hosted developer environments. The reasoning is easy to understand. A new engineer joins the team. Instead of spending a day installing dependencies, configuring SDKs, setting up databases, and resolving version conflicts, the engineer clicks a button and receives a ready-to-use environment. Organizations gain consistency, security controls, and easier onboarding. Meanwhile, developers gain flexibility because they can access their workspace from almost anywhere.

The promise sounds compelling.

However, after the initial excitement wears off, a different question emerges:

Is the developer actually more productive?

That question ultimately led me to rethink my own setup.

The Developer Experience (DX) Gap: Dealing with Latency and Connectivity Issues

One aspect of cloud development is rarely discussed in marketing material: latency.

Not production latency.

Developer latency.

Every action during development is part of a feedback loop. You change code, run tests, wait for results, make another change, and repeat. The shorter that loop becomes, the easier it is to stay focused.

When everything runs locally, interactions feel almost instantaneous.

A build starts immediately.
A terminal responds immediately.
A search indexes immediately.
A database query executes immediately.

Once a remote development environment enters the picture, even small delays begin to accumulate. Most individual delays are measured in milliseconds or seconds, but development is made of thousands of tiny interactions. Eventually, those interruptions become difficult to ignore.

Figure 1: Developer Flow and Responsiveness

Figure 1. Illustrative comparison of perceived development responsiveness. The chart visualizes the productivity impact of local feedback loops versus remote interactions and is intended as a conceptual representation rather than benchmark data.

The issue isn’t necessarily raw performance. Modern cloud environments can be incredibly powerful. The issue is that the developer is no longer working directly against the machine that executes the workload. Every edit, save, search, terminal command, and debugging session now depends on network quality.

A temporary connection issue might not affect production operations. However, it can absolutely affect concentration. And in software engineering, concentration is often the most valuable resource.

The Financial Cost: Is Your Docker-in-the-Cloud Setup Secretly Expensive?

The second realization came after reviewing costs. Many developers assume cloud development environments are inexpensive because the individual hourly rates appear small. However, usage-based pricing accumulates surprisingly quickly.

According to GitHub’s pricing documentation, Codespaces charges based on compute usage and storage consumption. Larger machine types increase costs proportionally, and long-running environments can generate significant monthly expenses.

Let’s consider a simple example.

GitHub currently lists a 2-core Codespace at approximately $0.18 per hour and a 4-core environment at approximately $0.36 per hour. A full-time developer working 40 hours per week could potentially reach the following compute costs before considering storage.

Figure 2: Illustrative Weekly Development Environment Cost

Figure 2. Example weekly costs derived from publicly documented GitHub Codespaces hourly pricing. Storage costs are not included

Now compare those recurring expenses with a modern developer workstation.

A powerful local machine may require a larger upfront investment, but that cost is fixed. After the hardware is purchased, local builds, databases, containers, and IDE workloads generally do not incur additional hourly charges.

For individual developers and smaller teams, that difference becomes increasingly difficult to ignore.

Returning to Local-First: Tools That Make Local Development as Powerful as the Cloud

The argument for cloud development used to be straightforward:

Local environments are messy.

Fortunately, that is becoming less true every year. Modern tooling has dramatically improved the local development experience.

For example, Docker allows applications to run inside reproducible containers. The same Docker image can be used locally, in CI pipelines, and in production. Meanwhile, Dev Containers enable developers to standardize development environments without requiring everyone to manually install identical dependencies.

This means the historical choice between:

consistency
local performance

is no longer as binary as it once was.

Today, a developer can combine:

Docker
Dev Containers
Local Kubernetes clusters
Testcontainers
Local databases
Modern IDEs

and create an environment that feels remarkably close to production while still retaining local responsiveness. In my experience, this combination delivers the best of both worlds.

The workflow remains highly reproducible. However, builds, debugging sessions, log inspection, and experimentation happen at local-machine speed. And speed matters.

Not because developers are impatient, but because software development is fundamentally about maintaining momentum.

When Cloud Still Makes Sense: Balancing Local Efficiency with Production Parity

Despite my preference for local-first development, abandoning the cloud entirely would be a mistake. There are situations where cloud environments remain the better option.

For example, large organizations often onboard dozens or hundreds of developers. Standardized cloud environments eliminate many support issues and ensure everyone starts from the same baseline. Similarly, highly regulated industries may prefer development environments that never leave managed infrastructure.

Cloud development also shines when projects require resources that most laptops cannot provide. Running large-scale data processing jobs, distributed test environments, GPU workloads, or multi-service integration tests often makes more sense remotely.

The ideal approach is usually not local versus cloud. Instead, it is local and cloud.

A practical workflow might look like this:

Develop locally.
Run unit tests locally.
Debug locally.
Push code.
Execute integration testing in the cloud.
Validate production parity through CI/CD pipelines.
Deploy through managed infrastructure.

This model keeps everyday development fast while still benefiting from cloud scalability.

Conclusion: Optimize for Speed of Thought, Not Just Parity with Production

For years, the industry has focused heavily on production parity. That focus is understandable because software should behave consistently across environments. However, production parity is only one side of the equation. The other side is developer productivity.

If cloud-hosted environments introduce friction, delay feedback loops, or quietly generate costs that exceed expectations, then they deserve scrutiny just like any other engineering decision.

The longer I work with modern development tools, the more I find myself returning to a simple principle:

Optimize for speed of thought.

When an idea appears, the shortest path from idea to implementation is often the most valuable workflow you can build. For many developers in 2026, that path is leading back to a surprisingly familiar place: the local machine.

What We Have Learned

Cloud-based development environments solve many real problems, particularly around onboarding, standardization, and production parity. However, they can also introduce latency, increase operational costs, and slow down the day-to-day feedback loop that developers rely on. Modern tools such as Docker, Dev Containers, and local Kubernetes distributions have significantly reduced the traditional disadvantages of local development.

As a result, many developers are rediscovering a local-first approach that combines fast iteration locally with cloud infrastructure for testing, validation, and deployment.

Sources

GitHub Codespaces Billing Documentation:
GitHub Pricing Calculator: https://github.com/pricing/calculator
GitHub Codespaces Product Documentation:

Tags

[DEALS] Mail Backup X Individual Edition: Lifetime Subscription (72% off) & Other Deals Up To 98% Off – Offers End Soon!

Java Code Geeks — Thu, 09 Jul 2026 10:30:30 +0000

Meta JCG

[DEALS] Mail Backup X Individual Edition: Lifetime Subscription (72% off) & Other Deals Up To 98% Off – Offers End Soon!

Hello fellow geeks,

Fresh offers await you on our Deals store, please have a look!

Mail Backup X Individual Edition: Lifetime Subscription
(72% off)

Ending soon // by Java Code Geeks

Perfect Solution for Mail Backup, Archiving, Email Management, & Mail Conversion!

MacMagic: Lifetime Upgrades License
(70% off)

Microsoft Windows 11 Pro
(94% off)

Microsoft Visual Studio Professional 2026
(93% off)

Microsoft Office 2024 Professional Plus: Lifetime License
(78% off)

OysterVPN: VPN Lifetime Subscription
(85% off)

PDF Expert Premium Plan: Lifetime Subscription (Mac)
(42% off)

Plantum – AI Plant Identifier Premium Plan: Lifetime Subscription (For iOS Only)
(66% off)

PDNob Pro PDF Editor: Lifetime Subscription
(85% off)

Shells Personal Cloud Computer: 1-Yr Subscription
(54% off)

Scramble Cloud Storage: Lifetime Subscription (2TB)
(65% off)

Tags

Zero-Trust Architecture for Backend Engineers: What It Actually Means Beyond the Marketing

Eleftheria Drosopoulou — Thu, 09 Jul 2026 05:10:00 +0000

Core Java

Zero-Trust Architecture for Backend Engineers: What It Actually Means Beyond the Marketing

A few years ago, securing a backend system was relatively straightforward. Applications lived inside a corporate network, databases sat behind a firewall, and VPN access was often considered sufficient protection.

Today, that assumption feels almost outdated.

Modern Java applications run across cloud platforms, Kubernetes clusters, managed databases, CI/CD pipelines, SaaS integrations, and distributed teams. Consequently, the idea of a trusted internal network has slowly disappeared. This reality is exactly why the concept of Zero-Trust Architecture (ZTA) has become so important.

The problem is that Zero Trust is often presented as a product category rather than what it actually is: a security philosophy.

According to the official NIST SP 800-207 Zero Trust Architecture guidance, trust should never be granted merely because a request originates from a particular network location. Instead, every user, device, service, and workload must continuously prove its identity and authorization before being allowed access to a resource.

For backend engineers, this creates a significant shift in thinking. Security is no longer about protecting a network perimeter. It is about protecting resources through identity, policy, and verification.

The Day the Network Boundary Stopped Mattering

Imagine a Java microservices environment.

A customer places an order through a web application. The request flows through an API gateway, reaches an Order Service, calls a Payment Service, updates Inventory, and finally triggers a notification.

Ten years ago, many organizations would have considered those services trustworthy simply because they operated on the same internal network.

However, what happens when:

A Kubernetes pod is compromised?
A service account is leaked?
A developer’s credentials are stolen?
A third-party integration is abused?

Once an attacker gets inside, the phrase “it’s internal traffic” suddenly loses its meaning.

This is precisely why NIST’s Zero Trust guidance moves security away from network-centric thinking and toward resource-centric protection. The question is no longer:

Is this request inside my network?

The question becomes:

Can this identity prove it should access this resource right now?
1 [csrc.nist.gov]

Security Priorities Have Fundamentally Changed

The easiest way to understand Zero Trust is to visualize the shift.

Figure 1. Conceptual comparison of architectural emphasis in traditional security models versus Zero Trust environments. The visualization is based on principles described in NIST SP 800-207 and does not represent measured industry benchmarks.

What’s interesting is not the exact numbers. Instead, the graph highlights a broader trend: Traditional security assumes trust and verifies selectively. Zero Trust assumes no trust and verifies continuously. That difference sounds small on paper, yet it completely changes how modern backend systems should be designed.

Identity Becomes the New Perimeter

One of the most important lessons for backend engineers is that identity has effectively become the new perimeter.

Think about all the entities operating inside a modern platform:

Users
APIs
Containers
Backend services
CI/CD pipelines
Databases
Scheduled jobs

Each of these should possess its own verifiable identity.

For example, when a Java Spring Boot service requests customer information from another microservice, that request should not be trusted simply because it originates from the cluster network.

Instead, the receiving service should know exactly:

Who is calling
What permissions exist
Which policies apply
Whether access should be granted

This identity-first model aligns closely with both the NIST Zero Trust Architecture framework and the CISA Zero Trust Maturity Model.

If your organization already uses technologies such as:

OAuth 2.0
OpenID Connect (OIDC)
Keycloak
Okta
Microsoft Entra ID

then you are already moving in the right direction.

You can learn more from the official NIST Zero Trust Architecture guidance and the CISA Zero Trust Maturity Model.

Mutual TLS: Trusting Services, Not Networks

One of the most practical Zero Trust technologies for backend teams is Mutual TLS (mTLS).

Most engineers understand TLS. When users visit a website, the browser validates the server certificate. mTLS goes one step further. Instead of only the client verifying the server, both sides verify each other.

Consider a Java-based architecture containing:

Payment Service
Orders Service
Inventory Service

Without mTLS, an attacker who gains internal network access may attempt to impersonate a service.

With mTLS in place, every service must present a valid certificate before communication is allowed. The result is simple: The network itself no longer grants trust. Identity does.

This is one of the clearest real-world examples of Zero Trust principles being applied to modern backend systems.

Least Privilege Is Where Real Security Happens

Many security discussions focus heavily on authentication. Authentication matters. However, authentication alone is not enough. A perfectly authenticated service with excessive permissions is still dangerous. Imagine a Customer Service application that only needs to read profile information.

Should it also have:

Access to payment data?
Administrative database rights?
Permission to modify user roles?

Of course not. Yet this exact situation exists in many production environments. Zero Trust promotes a principle known as least privilege, where identities receive only the permissions required to perform their job and nothing more. NIST explicitly emphasizes limiting access and enforcing authorization decisions at the resource level.

A useful example is a banking application. A transaction reporting service might need:

Read access to transaction records.
Read access to customer IDs.

It probably does not need:

Account management permissions.
User administration rights.
Database modification privileges.

Restricting access in this way dramatically reduces the impact of a breach.

The Hidden Benefit: Smaller Blast Radius

When discussing least privilege, I often hear developers ask:

“What’s the actual benefit?”

The answer is simple: containment. If an attacker compromises a low-privilege identity, the damage remains limited.

The graph below illustrates the concept.

Figure 2. Illustrative representation of how tighter authorization models reduce potential exposure after a compromised account or service identity. The chart visualizes a security principle rather than measured operational data

The important takeaway is not the exact values. Rather, it is the direction. As permissions become more targeted, the attacker’s potential reach shrinks significantly.

Zero Trust Is Continuous, Not One-Time

Another misconception is that Zero Trust simply means adding Multi-Factor Authentication.

MFA helps, but Zero Trust goes much further.

Traditional security often treated authentication as a one-time event:

User logs in.
User is trusted.
Session continues.

Zero Trust assumes trust can change at any moment.

For example:

Credentials may be stolen.
Devices may become unhealthy.
Certificates may expire.
Access behavior may become suspicious.

As a result, security decisions should be continuously evaluated using context and policy. This concept appears throughout both NIST and CISA guidance.

For backend engineers, this often translates into short-lived tokens, automated certificate rotation, centralized auditing, and policy-based authorization rather than static permissions.

Where Organizations Usually Invest First

Organizations rarely implement Zero Trust all at once.

Instead, they focus on specific areas first.

Figure 3. Visual representation inspired by the five-pillar approach described in CISA’s Zero Trust Maturity Model. Percentages are illustrative and used solely for comparison

The underlying pillars come directly from CISA’s guidance:

Pillar	Purpose
Identity	Verify who is requesting access
Devices	Validate endpoint trustworthiness
Networks	Secure communications
Applications	Enforce application policies
Data	Protect sensitive information

For Java engineers, identity and applications are often the most visible pillars because they directly influence authentication, authorization, APIs, and service communication.

Final Thoughts

The biggest mistake people make is thinking Zero Trust is a product they can purchase.

It isn’t. Zero Trust is a shift in mindset.

The most successful implementations don’t begin with expensive tools. They begin by questioning long-held assumptions:

Why do we trust this service?
Why does this account have so much access?
Why are we granting permissions based on network location?

Once those questions become part of everyday engineering decisions, Zero Trust stops being a security buzzword and starts becoming architecture.

For backend engineers, that may be the most important lesson of all: in modern distributed systems, trusted networks are temporary, but verified identities can be continuously validated.

What We Have Learned

We explored why traditional network boundaries no longer provide meaningful security in cloud-native environments and how Zero Trust replaces location-based trust with identity-based verification. We examined the role of mutual TLS in service-to-service authentication, saw why least-privilege access dramatically reduces attack impact, and discussed the importance of continuous verification. Finally, we looked at the major investment areas within Zero Trust programs and what they mean for modern Java backend teams building distributed applications.

Sources

NIST SP 800-207: Zero Trust Architecture https://csrc.nist.gov/pubs/sp/800/207/final
CISA Zero Trust Maturity Model https://www.cisa.gov/zero-trust-maturity-model [paloaltonetworks.com], [csrc.nist.rip]
Microsoft Learn – Zero Trust Guidance https://learn.microsoft.com/security/zero-trust

Tags

Event-Driven vs. Request-Driven Architecture: How to Choose and When the Boundary Blurs

Eleftheria Drosopoulou — Wed, 08 Jul 2026 16:58:00 +0000

Software Development

Event-Driven vs. Request-Driven Architecture: How to Choose and When the Boundary Blurs

A decision-making framework for teams standing at the architectural fork between REST APIs and event streams.

Almost every architecture discussion eventually arrives at the same fork: should this service call that service directly, or should it publish an event and let something else react later? The two answers feel philosophically opposed — one is a conversation, the other is a broadcast — and teams often treat the choice as permanent and binary. In practice, the most resilient systems rarely commit fully to either side. They pick deliberately, service by service, and the boundary between the two models turns out to be far blurrier than the diagrams suggest.

Two Fundamentally Different Communication Models

Request-Driven (Synchronous)

A request-driven call is a direct question that expects a direct answer: a client sends a request, blocks or waits, and gets a response before moving on. REST, gRPC, and GraphQL all live here. The appeal is straightforward reasoning — the caller knows immediately whether the operation succeeded, and the flow of control is easy to trace by simply reading the code from top to bottom.

Event-Driven (Asynchronous)

An event-driven interaction inverts that relationship. A service publishes a fact — “order placed,” “payment captured” — without knowing or caring who, if anyone, is listening. Consumers react whenever they’re ready, on their own schedule. Platforms like Apache Kafka and cloud-native equivalents like AWS EventBridge exist specifically to make that decoupling durable and scalable.

The Real Trade-offs Behind the Buzzwords

Both models solve the same underlying problem — getting information from one part of a system to another — but they optimize for different failure modes and different mental models of time.

Dimension	Request-Driven	Event-Driven
Coupling	Tight; caller must know the callee’s address and contract	Loose; producer doesn’t know who consumes the event
Failure isolation	A downstream outage blocks the caller immediately	Downstream outage delays processing but doesn’t block the producer
Latency expectation	Immediate response, typically milliseconds	Eventual; consumers process on their own timeline
Debugging a single flow	Straightforward call stack to trace	Requires distributed tracing across producers and consumers
Consistency model	Naturally supports strong consistency	Naturally eventual, unless deliberately compensated for

Figure 1 — Qualitative comparison of request-driven and event-driven models across dimensions that most influence architecture decisions.

Neither column is objectively better, and that’s exactly the point most “microservices best practices” listicles gloss over. A payment authorization almost certainly wants the immediate certainty of a request-response call. A shipping notification, a recommendation-engine update, or an analytics pipeline almost certainly doesn’t need to block anything while it happens.

Where the Boundary Blurs: Hybrid Patterns in Practice

The cleanest architecture diagrams show a clear line between “the REST layer” and “the event layer.” Production systems rarely stay that tidy, and three patterns explain why.

The Outbox Pattern: A Request That Quietly Becomes an Event

A service might expose a perfectly ordinary synchronous REST endpoint for placing an order, while internally writing that order and a corresponding event to the same database transaction — the transactional outbox pattern. A separate process then reliably publishes the event afterward. From the caller’s perspective, it’s a request-driven interaction. Underneath, it’s already feeding an event-driven pipeline.

CQRS: An Event-Sourced Core with a Synchronous Front Door

Command Query Responsibility Segregation often pairs an event-driven write path with a request-driven read path. Writes are appended as events and processed asynchronously, while reads are served from a synchronously queried, denormalized projection. The two models coexist inside a single bounded context, each doing the job it’s actually good at.

Webhooks and Polling: Async Dressed Up as Sync

Public APIs frequently fake synchronicity over an inherently asynchronous process. A payment provider might return an immediate “pending” response, then deliver the real outcome later via a webhook — which is, underneath the HTTP framing, an event. Long-polling and Server-Sent Events blur the same line from the other direction, keeping a request open while waiting for something event-driven to happen.

Figure 2 — Illustrative distribution of how production systems tend to combine these models, based on commonly documented architectures at large-scale platforms rather than a pure either/or split.

A Practical Decision Framework

Instead of asking “should we be event-driven or request-driven,” a more useful question is which model fits each specific interaction. A short set of signals tends to point clearly in one direction.

Signal	Leans toward
Caller needs an immediate success/failure answer	Request-driven
Multiple unrelated services need to react to the same fact	Event-driven
Strong consistency is a hard business requirement	Request-driven
Producer and consumer scale independently or fail independently	Event-driven
The interaction is a simple, well-known two-party contract	Request-driven
New consumers should be addable without changing the producer	Event-driven

Before defaulting to one model system-wide, ask:

Does this specific interaction need an answer right now, or just needs to eventually happen?
How many consumers exist today, and how many are likely to exist in a year?
What’s the actual cost of eventual consistency here — seconds of staleness, or a real business risk?
Can we debug this flow in production with the tracing tools we already have?
Are we choosing event-driven because it fits, or because it’s currently fashionable?

What We Learned

Request-driven and event-driven architectures aren’t really competing philosophies — they’re two tools that trade immediate certainty for loose coupling, or vice versa, depending on what a specific interaction actually needs. The trade-offs are real and worth respecting: tight coupling and blocking failure on one side, eventual consistency and harder debugging on the other. But the sharp line between them tends to dissolve once you look closely at production systems, where patterns like the transactional outbox, CQRS, and webhook-based APIs deliberately blend both models within a single service. The healthiest architecture decision usually isn’t picking a side once — it’s asking the question separately for every interaction that crosses a service boundary.

Tags

How the JVM Decides What to Compile: Inside the JIT Tier System and Profiling Pipeline

Eleftheria Drosopoulou — Wed, 08 Jul 2026 05:50:00 +0000

Core Java

How the JVM Decides What to Compile: Inside the JIT Tier System and Profiling Pipeline

A conceptual walkthrough of C1, C2, tiered compilation, and why the JVM’s optimizer knows more about your code than you do.

Java is often described as a compiled language and an interpreted one, depending on who’s explaining it, and both answers are a little bit right. The JVM starts every method as interpreted bytecode, then quietly promotes the ones worth optimizing into native machine code — sometimes more than once, using two entirely different compilers with different priorities. This staged promotion is called tiered compilation, and understanding it explains a lot of otherwise mysterious JVM behavior, from slow warm-ups to sudden performance cliffs after a config change.

Why the JVM Doesn’t Just Compile Everything Upfront

Compiling every method to optimized native code the moment the application starts would sound like the fastest option, but it isn’t. Aggressive optimization takes real time and CPU, and most methods in a typical application run only a handful of times — compiling them at all would be wasted effort. The JVM’s actual strategy is closer to triage: run everything as interpreted bytecode first, watch closely to see which methods actually get hot, and spend the expensive optimization budget only where it will pay off.

This is the same idea behind why HotSpot got its name in the first place: the runtime is built around finding the small number of “hot” methods that dominate execution time, rather than treating every line of code as equally important.

Two Compilers, Two Different Jobs

C1: The Client Compiler

C1 exists to get a method out of the slow interpreter as quickly as possible. It applies a modest set of optimizations and compiles fast, prioritizing low compilation overhead over maximum runtime performance. C1 is also responsible for attaching lightweight profiling instrumentation to the compiled code, so the JVM keeps learning about the method’s behavior even after it stops being interpreted.

C2: The Server Compiler

C2 is the more aggressive, more patient optimizer. It performs deeper inlining, more thorough loop optimizations, and speculative techniques based on the profiling data gathered earlier, at the cost of a much longer and more CPU-intensive compilation process. C2 is reserved for methods that have proven, through actual measured execution, that they’re worth the investment.

The Five Levels of Tiered Compilation

Since Java 7, HotSpot runs both compilers together in a single pipeline rather than forcing a choice between them. A method moves through as many as five distinct execution levels, and the JVM decides the next step dynamically based on invocation counts, loop back-edge counts, and how busy each compiler’s queue currently is.

Level	Compiler	Profiling	Purpose
0	Interpreter	None	Default starting point for every method
1	C1	None	Fast exit for trivial methods that don’t need deeper analysis
2	C1	Light (invocation and back-edge counters)	Used under heavy C2 queue pressure
3	C1	Full profiling	Default path most hot methods take before C2
4	C2	None (already fully optimized)	Peak long-term performance for proven hot methods

The path from level 0 to level 4 is usually 0 → 3 → 4, but the JVM can route through level 2 instead of 3 when the C2 compilation queue is under pressure, trading some profiling depth for reduced compiler contention. This adaptive routing is part of why two runs of the same application can warm up slightly differently depending on system load.

Figure 1 — Illustrative relationship between compilation cost and optimization depth across the five tiers. Level 0 has no compilation cost since it’s purely interpreted.

Profiling: The Data C2 Depends On

C2’s aggressive optimizations aren’t guesses — they’re built on real profiling data collected while a method ran at levels 2 or 3. Branch frequencies, actual types seen at a call site, and which paths through the code are common versus rare all feed into decisions like inlining a virtual call or eliminating a null check the profiler never saw fail. This is what makes C2’s output potentially more efficient than what an ahead-of-time compiler could produce with no runtime information at all: it optimizes for the code paths your application actually takes, not every path that’s theoretically possible.

That same speculation is also why deoptimization exists. If an assumption baked into optimized code turns out to be wrong later — a previously monomorphic call site suddenly sees a new type, for instance — the JVM discards the optimized version and falls back to the interpreter for that method until it can safely recompile.

Figure 2 — Qualitative comparison of the interpreter, C1, and C2 across dimensions that matter for warm-up and steady-state performance.

What This Means for How You Write and Benchmark Code

The tiered model explains two things developers frequently misdiagnose. First, benchmarking a method for a few hundred iterations often measures interpreted or C1 performance, not the C2-optimized steady state the code will reach in production — this is precisely why microbenchmarking tools like JMH insist on explicit warm-up iterations before measuring. Second, short-lived processes such as CLI tools or serverless functions may never accumulate enough invocations to reach level 4 at all, meaning C2’s deepest optimizations simply never get a chance to apply.

Keep these in mind when reasoning about JIT behavior:

A method needs to run many times before it’s considered worth C2’s more expensive optimization pass.
Warm-up time in benchmarks and short-lived processes reflects real tiered compilation behavior, not a measurement artifact to ignore.
Deoptimization is a normal, expected safety net for speculative optimizations, not a sign of something broken.
Compiler queue pressure can change which tier a method routes through, so behavior can vary slightly run to run under load.

What We Learned

Tiered compilation exists because no single strategy — pure interpretation, pure fast compilation, or pure aggressive optimization — serves an entire application’s lifetime well on its own. C1 gets hot methods out of the interpreter quickly while continuing to gather profiling data, and C2 spends its heavier optimization budget only on methods that have already proven, through real execution counts, that the investment will pay off. The five-level pipeline that connects them is the JVM continuously re-deciding, method by method, how much it’s worth knowing about your code before committing to a final optimized version.

Tags

Understanding Garbage Collection Pauses: Why Stop-the-World Still Happens and What the JVM Is Actually Doing

Eleftheria Drosopoulou — Tue, 07 Jul 2026 16:45:00 +0000

Core Java

Understanding Garbage Collection Pauses: Why Stop-the-World Still Happens and What the JVM Is Actually Doing

A conceptual guide to safepoints, GC roots, and why even modern collectors like ZGC and Shenandoah cannot always avoid pausing your application.

“Stop-the-world” sounds like a relic from an older generation of garbage collectors, something G1, ZGC, and Shenandoah were supposed to have solved for good. And in a very real sense, they have — modern collectors have pushed pause times down from seconds to single-digit milliseconds or less. But the phrase “pause-free” that shows up in marketing slides is doing a lot of quiet rounding. Every collector, no matter how advanced, still needs to stop your application threads occasionally. Understanding why reveals a lot about how the JVM actually manages memory underneath the abstraction.

What a GC Pause Actually Is

A garbage collection pause is not the JVM being slow. It’s the JVM deliberately freezing every application thread so it can inspect or move memory without anything changing underneath it mid-operation. Think of it like needing to relabel every box in a moving truck: you can’t safely do that while someone else is still loading and unloading boxes at the same time. For at least some part of the process, everyone has to stop moving boxes.

The length of that freeze is what most tuning conversations obsess over, but the more interesting question is why the freeze has to happen at all, even in collectors specifically engineered to avoid it.

Safepoints: The Real Reason Threads Stop

A safepoint is a point in a thread’s execution where its internal state is fully known and consistent — every register, every stack reference, every object pointer is exactly where the JVM expects it to be. The JVM cannot simply pause a thread at an arbitrary instruction, because the thread might be mid-way through updating a pointer, leaving memory in a state that’s unsafe to inspect.

Instead, the JVM waits until every thread reaches one of these well-defined checkpoints — typically at method return points, loop back-edges, and allocation sites — and only then does the actual pause begin. This is why a tight loop with no method calls can occasionally delay a GC pause longer than expected: the thread simply hasn’t reached a safepoint yet. This mechanism is part of why even a collector designed to do almost everything concurrently still needs a brief, coordinated moment where all threads agree to stop.

GC Roots: What the Collector Must Find Before It Can Move Anything

Garbage collection works by tracing reachability, not by counting references directly. It starts from a set of GC roots — local variables on the stack, static fields, active JNI references, and a handful of other well-known anchor points — and walks outward through every reference it finds. Anything reachable from a root survives; anything unreachable is garbage.

Root scanning has to happen while the world is at least briefly frozen, because the set of roots can change from one instruction to the next as a thread pushes and pops stack frames. Even collectors that perform the bulk of their marking and compaction concurrently with your application still need a short stop-the-world phase just to take an accurate snapshot of the roots before releasing the threads to run alongside the collector again.

Why Even ZGC and Shenandoah Aren’t Pause-Free

Both ZGC and Shenandoah were built specifically to decouple pause time from heap size, using concurrent marking and concurrent compaction so that most of the expensive work happens while your application keeps running. This is a genuine engineering achievement, and it’s why both collectors advertise pause times in the low single-digit milliseconds even on multi-terabyte heaps.

What neither collector eliminates is the short root-scanning pause described above, along with brief pauses to flip internal bookkeeping state between GC phases. The difference from older collectors isn’t zero pauses — it’s that the remaining pauses no longer scale with heap size, so a 4GB heap and a 400GB heap see roughly the same tiny pause instead of a proportionally larger one.

Collector	Compaction style	Pause scales with heap size?
Serial	Fully stop-the-world	Yes
Parallel	Fully stop-the-world, multi-threaded	Yes
G1	Mostly concurrent marking, stop-the-world evacuation	Partially (pause-target based)
ZGC	Concurrent marking and relocation	No
Shenandoah	Concurrent marking and compaction	No

Figure 1 — Illustrative maximum pause time by collector, shown on a logarithmic scale, based on publicly documented design goals from the OpenJDK GC tuning guide and the ZGC and Shenandoah project pages. Actual pauses depend heavily on workload and configuration.

Comparing the Modern Low-Pause Collectors

Figure 2 — Qualitative comparison of G1, ZGC, and Shenandoah across dimensions relevant to production tuning decisions.

G1 remains the JDK’s default for good reason: it balances throughput and pause time reasonably well for most general-purpose workloads and has years of production hardening behind it. ZGC and Shenandoah pull ahead specifically when heap sizes grow large and pause consistency matters more than raw throughput, such as latency-sensitive trading systems or large in-memory caches.

A Practical Checklist for Diagnosing Pause Problems

When a pause shows up somewhere it shouldn’t, check:

Is this actually a GC pause, or a safepoint delay caused by a thread taking too long to reach a safepoint (a tight loop with no back-edges, for example)?
Does the pause scale with heap size? If so, you’re likely still bound by a collector whose compaction isn’t fully concurrent.
Are GC logs enabled with enough detail to distinguish root-scanning pauses from full evacuation pauses?
Has the allocation rate spiked, forcing more frequent collection cycles regardless of collector choice?
Would switching to a concurrent collector actually help, or is the real issue application-level allocation pressure that no collector can fully hide?

What We Learned

Stop-the-world pauses persist in every JVM garbage collector, including ZGC and Shenandoah, because safepoints and GC root scanning both require a brief, consistent snapshot of every thread’s state that simply cannot be taken while those threads keep running. What has genuinely changed is that modern collectors decoupled pause length from heap size, turning pauses that once scaled with gigabytes of live data into a near-constant, low-millisecond cost regardless of how large the heap grows. Understanding safepoints and GC roots reframes the tuning conversation: the goal was never to eliminate pauses entirely, but to make them small and predictable enough that they stop being the bottleneck.

Tags

Markdown Rendering with commonmark-java

Yatin Batra — Tue, 07 Jul 2026 12:25:55 +0000

Enterprise Java

Markdown Rendering with commonmark-java

Markdown has become the de facto standard for writing documentation, technical blogs, README files, knowledge bases, and collaborative content. While Markdown itself is easy to write, applications often need to convert Markdown into HTML before displaying it in browsers. The commonmark-java library provides a robust Java implementation of the CommonMark specification. It allows developers to parse Markdown into an Abstract Syntax Tree (AST), inspect and manipulate nodes, customize rendering, and generate HTML output with minimal effort.

1. Overview

CommonMark is a standardized specification for Markdown. Unlike earlier Markdown implementations that behaved differently across platforms, CommonMark ensures consistent parsing rules. The commonmark-java library is the official Java implementation that fully supports the CommonMark specification while providing extension points for customization.

1.1 Key Features of commonmark-java

Markdown Parsing: The library parses raw Markdown text and converts it into a structured Abstract Syntax Tree (AST). Instead of processing plain text directly, applications work with a hierarchy of nodes representing headings, paragraphs, lists, links, images, code blocks, tables, and other Markdown elements. This structured representation simplifies content analysis and transformation.
HTML Rendering: Once the Markdown document has been parsed into an AST, the HtmlRenderer traverses the tree and generates standards-compliant HTML. The renderer correctly handles nested elements, inline formatting, block elements, and escaping of special characters, ensuring safe and consistent HTML output.
AST Traversal: Every Markdown document is represented as an Abstract Syntax Tree (AST), where each Markdown construct is a separate node. Developers can traverse this tree using the Visitor pattern to inspect, analyze, validate, or transform specific parts of the document before rendering it.
Custom Node Visitors: The library provides visitor APIs that allow developers to perform custom operations while traversing the parsed document. For example, applications can extract headings for a table of contents, collect hyperlinks, validate Markdown syntax, count images, generate summaries, or build search indexes without modifying the original document.
Custom HTML Rendering: Developers can customize how individual Markdown elements are rendered into HTML. Using custom node renderers and attribute providers, applications can add CSS classes, inject custom attributes, modify generated tags, wrap elements inside additional HTML, or replace the default rendering behavior entirely to meet specific application requirements.
Extension Support: The core library can be extended through optional modules that introduce additional Markdown features. Extensions enable support for functionality such as tables, task lists, autolinks, strikethrough, footnotes, and other advanced Markdown constructs while maintaining compatibility with the CommonMark specification.
GitHub-Flavored Markdown (GFM) Extensions: Through extension modules, commonmark-java supports many GitHub-Flavored Markdown features commonly used in README files and documentation. These include tables, task lists, automatic URL detection, and strikethrough formatting, making it suitable for rendering GitHub-style content.
High Performance: The library is lightweight, efficient, and optimized for production use. Its parser and renderer are designed to process large Markdown documents with minimal memory overhead, making it well suited for documentation portals, blogging platforms, content management systems, and other high-throughput Java applications.

2. Understanding the commonmark-java Library

The library is organized into multiple components that work together.

Component	Description	Purpose	Common Use Cases
Parser	The `Parser` is the entry point of the commonmark-java library. It reads raw Markdown text and converts it into a structured Abstract Syntax Tree (AST), where each Markdown element becomes a node in the document tree.	Transform Markdown syntax into an object model that can be traversed, analyzed, modified, or rendered.	Parsing README files, documentation, blog posts, user-generated content, knowledge-base articles, and Markdown documents.
Node	Every Markdown construct is represented as a subclass of `Node`. Examples include `Document`, `Heading`, `Paragraph`, `Text`, `Link`, `Image`, `BulletList`, `Code`, and many others. Together, these nodes form the AST.	Provide a structured representation of the Markdown document that applications can inspect and manipulate.	Extracting headings, finding links, counting images, validating document structure, or transforming specific Markdown elements.
Visitor	The Visitor API provides a convenient mechanism for traversing the AST. Developers typically extend `AbstractVisitor` and override only the node types they want to process, while allowing the framework to continue traversing child nodes automatically.	Traverse the document tree and perform custom operations on selected Markdown elements.	Building a table of contents, collecting hyperlinks, generating search indexes, validating content, extracting metadata, or producing document statistics.
HtmlRenderer	The `HtmlRenderer` walks through the parsed AST and generates standards-compliant HTML. It correctly renders headings, paragraphs, emphasis, lists, block quotes, code blocks, links, images, and other Markdown elements while preserving their hierarchy.	Convert the parsed Markdown document into browser-friendly HTML.	Rendering documentation websites, CMS pages, blogs, developer portals, knowledge bases, email templates, and web applications.
Extensions	commonmark-java supports optional extension modules that add functionality beyond the core CommonMark specification. These extensions integrate seamlessly with both the parser and renderer.	Enable additional Markdown capabilities without changing applicationcode significantly.	GitHub-Flavored Markdown (GFM), tables, task lists, strikethrough, automatic links, footnotes, custom syntaxes, and organization-specific Markdown extensions.

2.1 Common Use Cases

Use Case	Description	Benefit
Documentation Platforms	Render Markdown-based documentation into responsive HTML pages for developer portals, product documentation, API references, and user guides.	Enables technical writers to author documentation in Markdown while automatically generating consistent and browser-friendly HTML.
Knowledge Bases	Store articles and FAQs in Markdown format and render them dynamically when users access the content.	Simplifies content management while keeping documents lightweight, portable, and easy to edit.
Blog Engines	Convert Markdown blog posts into HTML before publishing them on websites or content management systems.	Allows authors to focus on writing content while the application automatically generates clean and standards-compliant HTML.
Search Engines	Extract plain text from Markdown documents using `TextContentRenderer` for indexing and searching.	Improves search accuracy by indexing readable text instead of Markdown syntax or HTML markup.
Content Validation	Traverse the Abstract Syntax Tree (AST) using visitors to inspect headings, links, images, code blocks, and other Markdown elements.	Helps validate document structure, enforce formatting rules, detect broken links, and generate document statistics.
Custom Content Management Systems (CMS)	Customize the generated HTML by implementing custom node renderers and attribute providers based on application-specific requirements.	Produces branded, SEO-friendly, and framework-compatible HTML while maintaining the simplicity of Markdown authoring.
Static Site Generators	Parse Markdown files and generate static HTML pages during the build process.	Enables fast website generation with minimal runtime overhead and improved page loading performance.
Developer Tools and IDE Plugins	Provide live Markdown previews, syntax analysis, and document transformation features inside development environments.	Enhances the authoring experience by offering real-time rendering, validation, and preview capabilities.
Email and Report Generation	Author reports or email templates in Markdown and convert them into HTML before sending or publishing.	Reduces template complexity while generating rich, well-formatted HTML content automatically.

2.2 Advantages

Official CommonMark implementation for Java
Simple and intuitive API
AST-based parsing enables advanced processing
Custom HTML rendering support
Visitor pattern for node traversal
Extension support for additional Markdown features
High performance and production-ready
Suitable for documentation, blogs, CMS, and developer tools

2.3 Limitations

The core library converts Markdown to HTML, not HTML to Markdown.
GitHub-Flavored Markdown features require additional extension modules.
Complex rendering customizations require familiarity with the node renderer APIs.

3. Parsing and Rendering Markdown

3.1 Maven Dependency

Add the following Maven dependency to your project’s pom.xml file to include the commonmark-java library.

<dependency>
    <groupId>org.commonmark</groupId>
    <artifactId>commonmark</artifactId>
    <version>stable__jar__version</version>
</dependency>

3.2 Parsing Markdown and Rendering HTML

3.2.1 Sample Markdown Input

Consider the following sample Markdown document that contains headings, bold text, a bullet list, and a hyperlink. We will use this document throughout the examples to demonstrate parsing, traversing the AST, and rendering HTML using the commonmark-java library.

# Java Guide

Welcome to **CommonMark**.

## Features

- Parser
- Renderer
- Visitor

Visit https://example.com

3.2.2 Java Example

The following example demonstrates the complete workflow of using the commonmark-java library. It creates a parser, converts a Markdown document into an Abstract Syntax Tree (AST), renders the parsed document as HTML, traverses the AST using the Visitor pattern to inspect individual nodes, and finally extracts the plain text content from the Markdown document.

// CommonMarkExample.java
import org.commonmark.node. * ;
import org.commonmark.parser.Parser;
import org.commonmark.renderer.html.HtmlRenderer;
import org.commonmark.renderer.text.TextContentRenderer;

public class CommonMarkExample {

  public static void main(String[] args) {
    String markdown = "# Java Guide\n\n" + "Welcome to **CommonMark**.\n\n" + "## Features\n\n" + "- Parser\n" + "- Renderer\n" + "- Visitor\n";

    // Create parser
    Parser parser = Parser.builder().build();
    // Parse markdown
    Node document = parser.parse(markdown);

    // Render HTML
    HtmlRenderer renderer = HtmlRenderer.builder().build();
    String html = renderer.render(document);
    System.out.println("Generated HTML");
    System.out.println(html);

    // Process parsed nodes
    document.accept(new AbstractVisitor() {
      @Override
      public void visit(Heading heading) {
        System.out.println("Heading Level : " + heading.getLevel());
        visitChildren(heading);
      }

      @Override
      public void visit(Text text) {
        System.out.println("Text : " + text.getLiteral());
      }

      @Override
      public void visit(BulletList bulletList) {
        System.out.println("Bullet List");
        visitChildren(bulletList);
      }

      @Override
      public void visit(ListItem item) {
        System.out.println("List Item");
        visitChildren(item);
      }
    });

    // Render plain text (Markdown -> Text)
    TextContentRenderer textRenderer = TextContentRenderer.builder().build();
    String plainText = textRenderer.render(document);
    System.out.println("\nExtracted Text");
    System.out.println(plainText);
  }
}

3.2.2.1 Code Explanation

The example begins by importing the required classes from the commonmark-java library for parsing Markdown, rendering HTML, traversing the Abstract Syntax Tree (AST), and extracting plain text. Inside the main() method, a sample Markdown document is created as a Java string containing headings, bold text, and a bullet list. A Parser instance is then created using the builder pattern, and the parse() method converts the Markdown into a Document node, which serves as the root of the AST. Next, an HtmlRenderer is initialized to traverse the AST and generate standards-compliant HTML, which is stored in a string and printed to the console. The example then demonstrates AST traversal by invoking the accept() method on the document and passing an anonymous implementation of AbstractVisitor. The visitor overrides the visit() methods for Heading, Text, BulletList, and ListItem nodes to print information about each Markdown element encountered during traversal, while the visitChildren() method ensures that child nodes are recursively visited. Finally, the program creates a TextContentRenderer instance to render the same parsed document as plain text by removing all Markdown formatting, demonstrating how a single parsed AST can be reused for multiple purposes such as HTML generation, document analysis, metadata extraction, content validation, search indexing, and plain-text rendering without requiring the Markdown document to be parsed again.

3.2.2.2 Code Output

The output demonstrates the three major capabilities of the commonmark-java library. The first section, Generated HTML, shows that the Markdown document has been successfully converted into standards-compliant HTML, where headings become <h1> and <h2> elements, bold text is rendered using the <strong> tag, and the Markdown bullet list is transformed into an unordered HTML list (<ul> and <li>). The second section displays the output produced by the custom AbstractVisitor, which traverses the Abstract Syntax Tree (AST) and prints information about each node encountered, including heading levels, text nodes, bullet lists, and individual list items, demonstrating how developers can inspect and process Markdown elements programmatically. Finally, the Extracted Text section illustrates the output generated by TextContentRenderer, which removes all Markdown formatting and HTML-specific information to produce clean, plain text that can be used for search indexing, content previews, text analysis, or document summaries.

Generated HTML

<h1>Java Guide</h1>
<p>Welcome to <strong>CommonMark</strong>.</p>
<h2>Features</h2>
<ul>
<li>Parser</li>
<li>Renderer</li>
<li>Visitor</li>
</ul>

Heading Level : 1
Text : Java Guide

Text : Welcome to
Text : CommonMark

Heading Level : 2
Text : Features

Bullet List

List Item
Text : Parser

List Item
Text : Renderer

List Item
Text : Visitor

Extracted Text

Java Guide

Welcome to CommonMark.

Features

Parser

Renderer

Visitor

4. Customizing HTML Attributes Using AttributeProvider

One of the biggest advantages of commonmark-java is its highly customizable HTML rendering pipeline. Developers can override how individual Markdown nodes are rendered without modifying the parser itself. The following example adds a custom CSS class and security attributes to every generated hyperlink.

// CustomAttributeProviderExample.java
import java.util.Map;

import org.commonmark.node.Link;
import org.commonmark.node.Node;
import org.commonmark.parser.Parser;
import org.commonmark.renderer.html.AttributeProvider;
import org.commonmark.renderer.html.HtmlRenderer;

public class CustomAttributeProviderExample {

    public static void main(String[] args) {
        String markdown = "# CommonMark Demo\n\n" + "Visit [OpenAI](https://openai.com) for more details.";

        // Parse Markdown
        Parser parser = Parser.builder().build();
        Node document = parser.parse(markdown);

        // Create custom HTML renderer
        HtmlRenderer renderer = HtmlRenderer.builder()
                .attributeProviderFactory(context ->
                        new AttributeProvider() {
                            @Override
                            public void setAttributes(Node node, String tagName, Map<String, String> attributes) {
                                if (node instanceof Link) {
                                    attributes.put("class", "external-link");
                                    attributes.put("target", "_blank");
                                    attributes.put("rel", "noopener noreferrer");
                                }
                            }
                        })
                .build();

        // Generate HTML
        String html = renderer.render(document);
        System.out.println("Generated HTML");
        System.out.println(html);
    }
}

5. Customizing Node Rendering

The renderer also allows replacing the default rendering logic for selected node types by registering a custom node renderer. This is useful when you want to change how headings, links, images, code blocks, or other elements are emitted.

// CustomNodeRendererExample.java
import java.util.Collections;
import java.util.Set;

import org.commonmark.node.Heading;
import org.commonmark.node.Node;
import org.commonmark.parser.Parser;
import org.commonmark.renderer.html.CoreHtmlNodeRenderer;
import org.commonmark.renderer.html.HtmlNodeRendererContext;
import org.commonmark.renderer.html.HtmlNodeRendererFactory;
import org.commonmark.renderer.html.HtmlRenderer;
import org.commonmark.renderer.html.HtmlWriter;

public class CustomNodeRendererExample {

    public static void main(String[] args) {
        String markdown = "# Java Guide\n\n" + "Welcome to CommonMark.\n\n" + "## Features";

        // Parse Markdown
        Parser parser = Parser.builder().build();
        Node document = parser.parse(markdown);

        // Create custom HTML renderer
        HtmlRenderer renderer = HtmlRenderer.builder()
                .nodeRendererFactory(CustomHeadingRenderer::new)
                .build();

        // Render HTML
        String html = renderer.render(document);
        System.out.println("Generated HTML");
        System.out.println(html);
    }

    static class CustomHeadingRenderer extends CoreHtmlNodeRenderer {
        private final HtmlWriter html;

        public CustomHeadingRenderer(HtmlNodeRendererContext context) {
            super(context);
            this.html = context.getWriter();
        }

        @Override
        public Set<Class<? extends Node>> getNodeTypes() {
            return Collections.singleton(Heading.class);
        }

        @Override
        public void visit(Heading heading) {
            html.line();
            html.tag("section");
            html.tag("h" + heading.getLevel());
            visitChildren(heading);
            html.tag("/h" + heading.getLevel());
            html.tag("/section");
            html.line();
        }
    }
}

6. Conclusion

The commonmark-java library is a powerful and standards-compliant solution for processing Markdown in Java applications. Its parser builds a rich AST that can be traversed, analyzed, and transformed before rendering HTML, making it suitable for documentation platforms, blogging engines, content management systems, and developer tools. In addition to straightforward Markdown-to-HTML conversion, the library supports plain-text extraction, custom HTML attributes, and custom node renderers that allow developers to tailor the generated HTML to their application’s needs. While the core library does not provide HTML-to-Markdown conversion, it excels at Markdown parsing and rendering with excellent performance, extensibility, and adherence to the CommonMark specification.

Tags

API Versioning Strategies and Their Hidden Long-Term Costs

Eleftheria Drosopoulou — Tue, 07 Jul 2026 05:40:00 +0000

Software Development

API Versioning Strategies and Their Hidden Long-Term Costs

URL versioning, header negotiation, content negotiation, and why every versioning choice is a debt you will eventually pay.

Every API eventually needs to change, and every team eventually has the same meeting: how do we version this thing? The conversation usually ends quickly, because all the options look roughly equivalent on a whiteboard. They are not. Each strategy trades a small amount of upfront friction for a specific kind of long-term cost, and that cost rarely shows up until the API already has real consumers who can’t be broken.

This article walks through the three dominant approaches, what each one actually costs you two years in, and how to pick with open eyes rather than by copying whatever a popular API happened to do.

Why Versioning Never Feels Urgent Until It’s Overdue

A brand-new API has no versioning problem, because it has no history to protect yet. The decision gets made early, almost as an afterthought, often by whoever is setting up the routing layer. By the time it matters — when a breaking change is genuinely necessary — the original choice is already locked in, because switching versioning strategies is itself a breaking change for every existing client.

That’s the core trap: the versioning strategy is one of the few architectural decisions an API makes that is nearly impossible to walk back later without repeating the exact pain it was meant to prevent.

The Three Common Strategies

URL Versioning

Putting the version directly in the path, such as /v1/orders or /v2/orders, is by far the most visible and easiest strategy to explain to a new consumer. It’s also the easiest to cache, log, and route, since the version is right there in every request line. The hidden cost appears once several versions are live at once: routing logic, documentation, and test suites all multiply, and old versions tend to linger far longer than anyone intended, because deleting a URL path feels more final than deprecating a header value.

Header-Based Versioning

Here the version travels in a custom request header, such as Api-Version: 2024-06-01, while the URL itself stays stable. This keeps URLs clean and semantically meaningful, which plays nicely with REST’s original intent that a URL identifies a resource, not a revision of an API. The cost shifts to discoverability: a version hidden in a header is invisible in browser address bars, harder to spot in casual debugging, and easy for a new engineer to overlook entirely when writing their first request.

Content Negotiation (Media Type Versioning)

The most formally “correct” approach, favored by REST purists, encodes the version inside the Accept header’s media type, for example application/vnd.myapi.v2+json. This aligns closely with HTTP’s original design for content negotiation and avoids polluting either the URL or inventing custom headers. The cost here is adoption friction: most client tooling, API gateways, and even some engineers are simply less familiar with this pattern, which tends to produce more support tickets and a steeper onboarding curve for new integrators.

Strategy	Biggest strength	Biggest long-term cost
URL versioning	Highly visible, cache-friendly, easy to explain	Old versions accumulate and rarely get retired
Header-based versioning	Clean, stable URLs	Low discoverability; easy to miss during debugging
Content negotiation	Closest to HTTP’s original design intent	Higher onboarding friction, less familiar tooling

How Major Public APIs Actually Handle This

Looking at how established platforms version their public APIs is a useful reality check, since these teams have already lived with their decisions for years. Stripe uses a date-based header approach, pinning each account to a specific API version string. GitHub also uses a header, alongside media-type based content negotiation for certain preview features. Meanwhile, platforms like the X (formerly Twitter) API and many Google Cloud APIs favor visible URL versioning, keeping the version front and center in the path.

Figure 1 — Versioning approach used by a sample of well-known public APIs (Stripe, GitHub, X/Twitter, Google Cloud, Shopify, PayPal, AWS, Slack).

There’s no single winner in this sample, and that itself is the lesson: mature platforms with enormous engineering budgets have made different choices, which strongly suggests the “right” answer depends more on your consumer base than on any universal best practice.

Comparing the Trade-offs Side by Side

Figure 2 — Qualitative comparison of the three strategies across dimensions that tend to matter most once an API has real production consumers.

Notice that no strategy scores well everywhere. URL versioning wins on discoverability and caching but loses on long-term tidiness, since old paths are painful to remove. Header-based versioning protects your URLs but hides the version from casual observers. Content negotiation is architecturally the cleanest, at the direct cost of being the least familiar to the average client developer.

The Debt That Compounds: Deprecation

Regardless of strategy, the real long-term cost isn’t choosing a versioning scheme — it’s failing to plan for retiring old versions from day one. A version without a documented sunset date tends to live forever, because there’s never a “good time” to force existing consumers to migrate. Teams that succeed here treat deprecation as a first-class feature of the API, not an afterthought bolted on once a version has become unmaintainable.

Before locking in a versioning strategy, ask:

Who are our primary consumers — internal teams, external partners, or the public — and how technically sophisticated are they?
Will old versions have a published sunset date and a defined maximum number of supported versions?
Does our infrastructure (gateways, CDNs, logging) already favor one strategy over the others?
How will a consumer discover that a new version exists at all, without reading documentation first?
Is the team prepared to say no to “just one more” long-lived version exception?

What We Learned

URL versioning, header-based versioning, and content negotiation all solve the same underlying problem, but each one shifts the pain to a different place: discoverability, URL cleanliness, or onboarding friction. None of them is free, and none of them can be swapped out later without repeating the very disruption they were meant to avoid. The strategy itself matters less than most teams assume — what actually determines the long-term cost is whether deprecation was planned from the very first version, or left to be figured out once too many versions are already live in production.

Tags

Java Code Geeks

When Services Wait Forever: A Practical Guide to Distributed Deadlocks

What Is a Distributed Deadlock?

How Resource Cycles Form Across Services

Figure 1: Distributed Deadlock Cycle

Why Traditional Deadlock Detection Fails

The Visibility Problem

A Realistic Example From Modern Architectures

Architectural Patterns That Break the Cycle

1. Consistent Resource Ordering

2. Timeouts and Leases

3. Avoid Synchronous Dependency Chains

Why Sagas Help

Figure 2: Traditional Transaction vs Saga

Design Principles for Deadlock-Resistant Systems

Conclusion

What We Have Learned

urther Reading

Thank you!

Jakarta EE 11 Under the Hood: What Spring Boot 4 Inherits and What It Ignores

Why Jakarta EE 11 Matters to Spring Developers

Jakarta Data 1.0: The Standardized Version of a Familiar Idea

Does Spring Boot 4 Benefit?

CDI 4.1: Cleaner Dependency Injection

Jakarta Validation 3.1: Better Support for Modern Java

Jakarta Persistence 3.2: The Upgrade Every Spring Developer Inherits

What Spring Boot 4 Still Ignores

The Bigger Trend Few Developers Notice

Conclusion

What We Have Learned

Further Reading

Thank you!

Why I’m Moving My Dev Setup Off the Cloud (And Back to Local)

Introduction: The Current Trend of “Everything in the Cloud”

The Developer Experience (DX) Gap: Dealing with Latency and Connectivity Issues

Figure 1: Developer Flow and Responsiveness

The Financial Cost: Is Your Docker-in-the-Cloud Setup Secretly Expensive?

Figure 2: Illustrative Weekly Development Environment Cost

Returning to Local-First: Tools That Make Local Development as Powerful as the Cloud

When Cloud Still Makes Sense: Balancing Local Efficiency with Production Parity

Conclusion: Optimize for Speed of Thought, Not Just Parity with Production

What We Have Learned

Sources

Thank you!

[DEALS] Mail Backup X Individual Edition: Lifetime Subscription (72% off) & Other Deals Up To 98% Off – Offers End Soon!

Thank you!

Zero-Trust Architecture for Backend Engineers: What It Actually Means Beyond the Marketing

The Day the Network Boundary Stopped Mattering

Security Priorities Have Fundamentally Changed

Identity Becomes the New Perimeter

Mutual TLS: Trusting Services, Not Networks

Least Privilege Is Where Real Security Happens

The Hidden Benefit: Smaller Blast Radius

Zero Trust Is Continuous, Not One-Time

Where Organizations Usually Invest First

Final Thoughts

What We Have Learned

Sources

Thank you!

Event-Driven vs. Request-Driven Architecture: How to Choose and When the Boundary Blurs

Two Fundamentally Different Communication Models

Request-Driven (Synchronous)

Event-Driven (Asynchronous)

The Real Trade-offs Behind the Buzzwords

Where the Boundary Blurs: Hybrid Patterns in Practice

The Outbox Pattern: A Request That Quietly Becomes an Event

CQRS: An Event-Sourced Core with a Synchronous Front Door

Webhooks and Polling: Async Dressed Up as Sync

A Practical Decision Framework

What We Learned

Thank you!

How the JVM Decides What to Compile: Inside the JIT Tier System and Profiling Pipeline

Why the JVM Doesn’t Just Compile Everything Upfront

Two Compilers, Two Different Jobs

C1: The Client Compiler

C2: The Server Compiler

The Five Levels of Tiered Compilation

Profiling: The Data C2 Depends On

What This Means for How You Write and Benchmark Code

What We Learned