foojay – a place for friends of OpenJDK

AWS Nitro and CPU Graviton Meets Unikernels

Angelo Rubini — Fri, 10 Apr 2026 16:26:25 +0000

Table of Contents

From Virtual Machines and Containers to UnikernelsProof of Concept Overview

Reproducibility and Artifacts
Local Build and Image Creation
Instance Creation on AWS
PoC Environment

Architectural Diagram of the PoCContainers vs Unikernels: A Stack Comparison

Container Stack
Unikernel Stack

Quarkus, Semeru, and Nanos on AWS Nitro GravitonAWS Nitro: Cloud-Native Capabilities Without KubernetesHypervisor IndependenceWhy This Matters for Java and Jakarta EEConclusion

The key message of this article is simple and strong: any Java or Jakarta EE application is already ready to benefit from the advantages of unikernels.

Java and Jakarta EE, including modern frameworks such as Quarkus, can immediately take advantage of the unikernel model without waiting for new languages, new runtimes, or radical rewrites.

With Nanos Unikernel, Java applications run unchanged: the JVM is not modified, the application is not rewritten, and the well-known Java promise of write once, run anywhere remains fully valid — even in a unikernel environment.

This represents a major shift: unikernels are no longer a research topic or a niche experiment, but a first-class deployment target for enterprise Java workloads.

From Virtual Machines and Containers to Unikernels

Cloud-native Java applications have traditionally been deployed on virtual machines and, more recently, inside containers orchestrated by Kubernetes. While containers brought improvements in portability and density, they also introduced additional layers of software complexity.

Unikernels remove these layers by compiling the application and its required runtime components into a single-purpose, minimal image that runs directly on a hypervisor.

With Nanos Unikernel, this model becomes practical for Java and Jakarta EE workloads.

Proof of Concept Overview

Reproducibility and Artifacts

For this Proof of Concept, all the build and deployment steps are fully reproducible.

The artifacts used are publicly available and were generated by the GitHub Actions workflow:

Repository and CI run: https://github.com/AngeloRubens/quarkus-faces-nanos/actions/runs/21218011985

These artifacts include the packaged Quarkus application and the IBM Semeru Runtime bundled for execution on Nanos Unikernel (ARM64).

Local Build and Image Creation

In the local environment, the Nanos unikernel image for AWS ARM64 was created using the following command:

ops image create \
  --imagename quarkusNanosArm64 \
  --package AngeloRubens/SemeruJREarm64Linux:25.0.1 \
  --arch arm64 \
  --nightly \
  -c configAws.json \
  -t aws

This step produces a bootable Nanos unikernel image containing:

the Quarkus application
the unmodified IBM Semeru Runtime (OpenJ9)
the minimal Nanos kernel required to run on ARM64

Instance Creation on AWS

Once the image was created and uploaded, the EC2 instance was launched directly from the unikernel image using:

ops instance create \
  quarkusNanosArm64 \
  --arch arm64 \
  -c configAws.json \
  -t aws

This workflow highlights a key point of the article: Java applications can be deployed as unikernels without introducing container images, container runtimes, or orchestration layers.

This article builds on the original Foojay article, where the application image was executed on Oracle Cloud Infrastructure (OCI). The goal of this Proof of Concept is to demonstrate that the same Nanos Unikernel image can be deployed on a different cloud provider and hypervisor without modification.

PoC Environment

Cloud provider: AWS
Instance type: t4g.small (ARM64)
CPU: AWS Graviton2
Hypervisor: AWS Nitro
Unikernel: Nanos (ARM64)
Runtime JAVA: IBM Semeru Runtime 25 for Arm64
Framework: Quarkus

This demonstrates that Nanos unikernels are hypervisor-agnostic and cloud-independent.

Architectural Diagram of the PoC

The application runs as a single unikernel image directly on top of the AWS Nitro hypervisor, without a guest operating system, container runtime, or Kubernetes node.

Containers vs Unikernels: A Stack Comparison

Container Stack

Hardware
Hypervisor
Guest Operating System
Container Runtime
Container Image
Java Runtime
Application

Unikernel Stack

Hardware
Hypervisor
Unikernel (Application + Runtime)

By removing unnecessary layers, unikernels reduce boot time, memory footprint, and attack surface.

Quarkus, Semeru, and Nanos on AWS Nitro Graviton

Quarkus is particularly well suited for this model thanks to its fast startup and low memory usage, while IBM Semeru provides a production-grade OpenJDK runtime. Combined with Nanos, the result is a highly efficient Java unikernel.

AWS Nitro: Cloud-Native Capabilities Without Kubernetes

AWS Nitro, like all modern hypervisors, already provides many of the foundational capabilities often associated with Kubernetes:

Strong isolation and security boundaries
Elastic scaling at the VM level
High-performance networking and storage
Hardware offloading for I/O and virtualization
Integrated observability and telemetry
Native IAM integration

Because these features are built directly into the cloud infrastructure, there is no technical requirement to add additional orchestration layers for many workloads.

Running Java applications as unikernels allows teams to:

Exploit hardware more efficiently
Reduce operational complexity
Lower infrastructure and operational costs

Hypervisor Independence

In the original article, the application image runs on the Oracle OCI hypervisor. In this Proof of Concept, the same image runs on AWS Nitro.

This confirms that Nanos unikernels are not tied to a specific cloud provider or hypervisor. The same Java application can be deployed consistently across environments.

Why This Matters for Java and Jakarta EE

Java and Jakarta EE can benefit today from unikernel advantages:

Faster boot times
Smaller memory footprint
Reduced attack surface
Simpler deployment model

Most importantly, this comes without changing existing applications or the JVM.

Unikernels with Nanos represent an evolutionary step, not a disruptive rewrite, for the Java ecosystem.

Conclusion

The cloud is evolving, and unikernels are becoming a practical deployment option for real-world workloads.

With Nanos Unikernel, Java, Jakarta EE, Quarkus, and IBM Semeru Runtime can fully exploit modern ARM64 cloud platforms such as AWS Graviton2 and the Nitro hypervisor — today, without compromise.

Reference:

The poc on aws Free Tier t4g.small until 31-Dec-2026: http://3.127.237.11:8080/index.xhtml

FooJay Link: https://foojay.io/today/java-jakarta-ee-and-the-evolution-of-the-cloud-with-nanos-unikernel/

Nanovms Link: https://nanovms.com/

Semeru JRE Repo ops nanos package https://repo.ops.city/v2/packages/AngeloRubens/SemeruJREarm64Linux/25.0.1/arm64/show

The post AWS Nitro and CPU Graviton Meets Unikernels appeared first on foojay.

Spring Boot Actuator Health for MicroProfile Developers

Luqman Saeed — Thu, 26 Mar 2026 09:30:00 +0000

Table of Contents

The Conceptual BridgeThe Conceptual BridgeEndpoint MappingWriting Health ChecksWriting Health Checks

Auto-Configured Health Indicators
Response Format and Status Codes
Security Considerations
Actuator’s Extended Capabilities
Practical Migration Tips
Conclusions

If you worked with MicroProfile Health, you already understand the value of exposing application health information through standardized endpoints. You know about liveness, readiness and startup probes. You implemented the HealthCheck interface and annotated your procedures with @Liveness, @Readiness and @Startup. Spring Boot Actuator follows a similar philosophy but takes a different architectural approach. This post will help you map your MicroProfile Health knowledge to Spring’s world.

The Conceptual BridgeThe Conceptual Bridge

At its core, Spring Boot Actuator serves the same purpose as MicroProfile Health: it provides a mechanism for validating the availability and status of your application in containerized environments. Both specifications recognize that modern cloud platforms like Kubernetes need machine-readable health information to make decisions about pod lifecycle management.

The fundamental concepts translate directly:

Liveness probes determine whether an application should be restarted
Readiness probes determine whether an application can accept traffic
Startup probes handle slow-starting applications before liveness takes over
Health status is aggregated from multiple contributors using a logical AND policy by default
HTTP status codes signal overall health (200 for UP, 503 for DOWN)

Endpoint Mapping

In MicroProfile Health 4.0, you work with four endpoints: /health/ready, /health/live, /health/started, and the combined /health. Spring Boot Actuator uses a similar structure with some naming differences.

The Actuator health endpoint lives at /actuator/health by default, with separate probe endpoints at /actuator/health/liveness and /actuator/health/readiness. These endpoints automatically become available when Spring detects a Kubernetes environment, exposing the application’s availability state through dedicated health indicators. Platforms like Payara Qube use these Actuator endpoints to monitor the health of Spring Boot applications, automatically detecting application status and managing container lifecycle based on the probe responses.

For Kubernetes deployments, you configure your probes similarly to what you’d do with MicroProfile:

livenessProbe:
  httpGet:
    path: "/actuator/health/liveness"
    port: 
readinessProbe:
  httpGet:
    path: "/actuator/health/readiness"
    port:

Writing Health ChecksWriting Health Checks

In MicroProfile Health, you implement the HealthCheck functional interface and return a HealthCheckResponse. The annotation determines whether it’s a liveness, readiness, or startup check. Spring Boot Actuator follows a similar pattern but uses the HealthIndicator interface instead.

MicroProfile Approach

@Readiness
@ApplicationScoped
public class DatabaseCheck implements HealthCheck {
    public HealthCheckResponse call() {
        return HealthCheckResponse.named("database")
            .withData("connection", "active")
            .up()
            .build();
    }
}

Spring Boot Actuator Approach

@Component
public class DatabaseHealthIndicator implements HealthIndicator {
    @Override
    public Health health() {
        return Health.up()
            .withDetail("connection", "active")
            .build();
    }
}

Notice the similarities: both use a builder pattern, both support additional data/details, and both return a status. The naming is derived from the class name in Spring (DatabaseHealthIndicator becomes “database”), while MicroProfile requires explicit naming in the response.

Auto-Configured Health Indicators

One area where Spring Boot Actuator differs from MicroProfile Health is the extensive set of auto-configured health indicators. While MicroProfile specifies that implementations should support reasonable out-of-the-box procedures, Spring Boot ships with indicators for databases, message brokers, caches, and more.

Available auto-configured indicators include checks for:

DataSource connections (database health)
Disk space monitoring
Elasticsearch, MongoDB, Neo4j, and other databases
Redis and Hazelcast caches
RabbitMQ and JMS message brokers
LDAP servers
SSL certificate validity

These indicators activate based on classpath detection. If you have a Redis client in your dependencies, the Redis health indicator appears. You can disable specific indicators through configuration properties like management.health.redis.enabled=false.

Response Format and Status Codes

Both specifications use JSON responses and HTTP status codes to communicate health status. MicroProfile Health 4.0 mandates specific status values (UP, DOWN) and HTTP codes (200, 503, 500). Spring Boot Actuator follows a similar convention but offers more flexibility in customization.

A typical Actuator health response looks like:

{
  "status": "UP",
  "components": {
    "db": {
      "status": "UP",
      "details": { "database": "PostgreSQL" }
    },
    "diskSpace": { "status": "UP" }
  }
}

Compare this to MicroProfile’s format using a “checks” array instead of a “components” object. The structure differs slightly, but the information conveyed is equivalent.

Security Considerations

Both specifications recognize that health endpoints may expose sensitive information. MicroProfile Health states that security is an opt-in feature that must not be enforced by default. Spring Boot Actuator takes a more secure-by-default approach: only the /health endpoint is exposed over HTTP by default, and when Spring Security is present, actuator endpoints are secured automatically.

Spring provides fine-grained control over what health information is displayed:

never: Details are never shown
when-authorized: Details shown only to authenticated users with proper roles
always: Details shown to all users

Actuator’s Extended Capabilities

While MicroProfile Health focuses solely on application health, Spring Boot Actuator provides a broader observability story. The health endpoint is just one of many available endpoints including metrics, environment properties, loggers, thread dumps, heap dumps, and more. This makes Actuator a more comprehensive solution for application monitoring, though it means learning a larger API surface.

Key additional endpoints include:

/actuator/metrics for application metrics
/actuator/env for environment properties
/actuator/loggers for runtime log level management
/actuator/info for build and git information
/actuator/prometheus for Prometheus-compatible metrics export

Practical Migration Tips

If you’re moving a MicroProfile application to Spring Boot or working on a team that uses both frameworks, here are key points to remember:

Replace annotations with components: Instead of @Liveness or @Readiness, create @Component beans implementing HealthIndicator and use health groups for organization.
Update endpoint paths: Change from /health/ to /actuator/health/ in your Kubernetes configurations.
Review auto-configured indicators: Check which indicators Spring activates based on your dependencies. You may need to disable some or configure others.
Configure security early: Spring’s secure-by-default approach means you may need to configure access rules for health endpoints to work with your infrastructure.
Consider reactive support: If you’re building reactive applications with WebFlux, use ReactiveHealthIndicator for non-blocking health checks.

Conclusions

Spring Boot Actuator and MicroProfile Health share the same goal: making applications observable and manageable in cloud-native environments. Your understanding of MicroProfile Health concepts transfers well to Spring. The main differences lie in the API surface (interface vs annotations), configuration approach (properties vs annotations), and scope (Actuator covers more than just health).

Whether you’re working with Jakarta EE and MicroProfile or Spring Boot, the underlying patterns for health checking remain consistent. Both ecosystems have learned from Kubernetes and cloud platform requirements, resulting in specifications that, while different in implementation details, serve the same operational needs.

For MicroProfile developers exploring Spring Boot, Actuator health will feel familiar. The learning curve is less about understanding new concepts and more about mapping the patterns you already know to a different syntax and configuration model.

The post Spring Boot Actuator Health for MicroProfile Developers appeared first on foojay.

Introducing the BoxLang Spring Boot Starter: Dynamic JVM Templating for Spring

Cristobal Escobar — Thu, 19 Mar 2026 14:20:02 +0000

Table of Contents

What is BoxLang? Zero-Config Spring Boot Integration

GradleGradle

From Controller to Template in Minutes Full Web Scopes — Out of the Box Hot-Reload During Development Configuration That Stays Out of Your Way Coexist With Any Other View Technology Requirements How It Works Under the Hood Get Started Professional Support

Spring Boot developers know the pain of evaluating view technologies. Thymeleaf is great — until you need more expressiveness. FreeMarker is powerful — until the syntax fights you. What if you could write templates in a dynamic JVM language that gives you the full power of the platform, feels natural, and requires zero setup to integrate?

Meet the BoxLang Spring Boot Starter.

TL;DR: Drop one dependency into your Spring Boot 3 app and start writing dynamic .bxm templates powered by BoxLang — a modern, expressive JVM language. Zero configuration. Full web scopes. 100% Java interoperable. Not only that, you get full access to BoxLang's framework capabilities so you can integrate tons of features into your Spring Boot applications:

Human & Fluent Scheduled Tasks
Enterprise Caching Engine
Cache Aggregator
Enhanced Concurrency BoxFutures
Attempts
Data Navigators
And so much more

Not only that, it is completely documented for you:

🌐 What is BoxLang?

BoxLang is a modern dynamic JVM language purpose-built for rapid application development. Think of it as what you'd get if Java's runtime, a scripting language's expressiveness, and a templating engine had a very productive meeting.

Key highlights:

☕ 100% Java interoperable — call any Java class, library, or Spring bean directly
🔩 Compiles to JVM bytecode — same performance guarantees you expect
🚀 Multi-runtime — run it on OS, Servlet containers, AWS Lambda, and more
🎨 Modern syntax — expressive, clean, and productive

// Access the BoxLang runtime directly from any Spring-managed bean
BoxRuntime runtime = BoxRuntime.getInstance();

✨ Zero-Config Spring Boot Integration

The starter follows Spring Boot's auto-configuration philosophy religiously. Add the dependency and you're done. No @EnableBoxLang. No manual bean registration. No XML.

GradleGradle

dependencies {
    implementation 'io.boxlang:boxlang-spring-boot-starter: 1.0.0'
}

Maven


    io.boxlang
    boxlang-spring-boot-starter
    1.0.0

Spring Boot's auto-configuration mechanism detects the starter on the classpath and wires BoxLangViewResolver, starts the BoxRuntime lifecycle, and registers all required beans automatically. Read more in our docs: https://boxlang.ortusbooks.com/getting-started/running-boxlang/spring-boot

🚀 From Controller to Template in Minutes

Your Spring MVC controllers stay exactly as they are. Return a view name, add model attributes — BoxLang handles the rest.

@Controller
public class HomeController {

    @GetMapping("/")
    public String home(Model model) {
        model.addAttribute("title", "Hello from BoxLang + Spring Boot!");
        model.addAttribute("framework", "Spring Boot 3");
        return "home"; // resolves to classpath:/templates/home.bxm
    }
}

Then write your template in src/main/resources/templates/home.bxm:





    #variables.title#


    #title#
    Framework: #framework#
    Rendered at: #dateTimeFormat( now(), "full" )#

Every attribute you add via model.addAttribute(...) is automatically injected into the BoxLang variables scope. No extra mapping, no boilerplate.

🌐 Full Web Scopes — Out of the Box

Unlike most view engines that only expose model data, BoxLang templates have access to the complete set of HTTP scopes natively, and the entire request/response servlet contexts.

Scope	Description
`variables`	Spring `Model` attributes + template-local variables
`url`	Query string parameters
`form`	Form POST data
`cgi`	Server/CGI environment variables
`cookie`	HTTP cookies
`request`	Per-request scoped storage


    
    #variables.title#

    
    Page: #url.page ?: 1#

    
    Theme: #cookie.theme ?: "light"#

🔥 Hot-Reload During Development

Switch to a file: prefix in a dev Spring profile and template edits take effect on the next request — no restarts required.

src/main/resources/application-dev.properties

boxlang.prefix=file:src/main/resources/templates/
boxlang.debug-mode=true

Activate it:

./gradlew bootRun --args='--spring.profiles.active=dev'

⚙️ Configuration That Stays Out of Your Way

All settings live under the boxlang.* namespace in application.properties or application.yml. Sensible defaults mean you only override what you need.

boxlang:
  prefix: classpath:/templates/
  suffix: .bxm
  debug-mode: false
  # runtime-home: /app/.boxlang  # great for containers

You can also supply a boxlang.json config file at src/main/resources/boxlang.json for advanced language-level settings like locale, timezone, and logging.

🔀 Coexist With Any Other View Technology

BoxLangViewResolver integrates cleanly into Spring MVC's resolver chain. If a .bxm template doesn't exist for a given view name, it returns null and Spring falls through to the next resolver — meaning Thymeleaf, FreeMarker, and BoxLang can all live in the same application without conflict.

# Lower number = higher priority in the resolver chain
boxlang.view-resolver-order=1

📋 Requirements

Dependency	Version
Java	21+
Spring Boot	3.4.x+
BoxLang	1.11.0+

🛠️ How It Works Under the Hood

For the curious Java developer:

Auto-configuration registers via META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports — the standard Spring Boot SPI.
BoxRuntime starts as a SmartLifecycle at phase Integer.MIN_VALUE + 100, ensuring it's ready before the first HTTP request hits.
BoxLangViewResolver resolves logical view names using prefix + viewName + suffix.
BoxLangView wraps HttpServletRequest/HttpServletResponse in a SpringBoxHTTPExchange, builds a WebRequestBoxContext (exposing all web scopes), injects the Spring Model into the variables scope, executes the template, and flushes to the response.

Clean separation of concerns. No magic you can't trace.

🎯 Get Started

git clone https://github.com/ortus-boxlang/boxlang-spring-boot-starter.git
cd boxlang-spring-boot-starter
./gradlew :test-app: bootRun

Open http://localhost:8080 and see BoxLang rendering live in your Spring Boot app.

📚 Full documentation: boxlang.ortusbooks.com

🔌 VS Code Extension: BoxLang VSCode Extension

💼 Professional Support

BoxLang is free and open source. Ortus Solutions offers commercial support, custom development, migration services, and enterprise modules for teams that need it.

👉 boxlang.io/plans

The post Introducing the BoxLang Spring Boot Starter: Dynamic JVM Templating for Spring appeared first on foojay.

JC-AI Newsletter #13

Miro Wengner — Thu, 05 Feb 2026 21:12:12 +0000

Two weeks have passed, and it is time to present a new collection of readings that may shape developments, utilization or ideas in the field of artificial intelligence in 2026.

While significant activity characterizes the AI field, many unresolved research, design, and implementation challenges continue to impact progress. Future advancement depends heavily on understanding the nature of these challenges to approach probabilistic problems from the appropriate directions. This JC-AI newsletter features insightful interviews with key figures in the field, enabling readers to ask the right questions and compare visions of an 'uncertain future' against current capabilities to maintain a grounded perspective.

article: Deep Researcher with Sequential Plan Reflection and Candidates Crossover (Deep Researcher Reflect Evolve)
authors: Saurav Prateek
date: 2026-01-28
desc.: This paper introduces Deep Researcher, a novel architecture that shifts the paradigm from latency-optimized parallel scaling to an accuracy-driven sequential refinement model. Within the development of Deep Research Agents (DRAs), two primary paradigms are considered, Parallel Scaling and Sequential Refinement. The Deep Researcher agent achieved an overall score of 46.21 on the Research Bench, demonstrating superior performance compared to existing agents, including Claude Researcher, Nvidia AIQ Research Assistant, Perplexity Research, Kimi Researcher, and Grok Deep Search. While these improvements are good, the field requires further research to address remaining challenges.
category: research

article: Manipulation in Prediction Markets: An Agent-based Modeling Experiment
authors: Bridget Smart, Ebba Mark, Anne Bastian, Josefina Waugh (University of Oxford)
date: 2026-01-28
desc.: The paper investigates the utilization of agentic systems in the economic field and their impact on prediction. First, the paper evaluates an agent-based model of a prediction market in which bettors with heterogeneous expertise, noisy private information, variable learning rates, and budgets observe the evolution of public opinion on a binary election outcome to inform their betting strategies in the market. The agentic system exhibits stability across experiments. The second area relates to experiments on how "whale" agents, a highly resourced minority with biased information, may distort market prices and for how long. The paper discusses interesting simulation results on how biased information may change the market from a long-term perspective.
category: research

article: Beyond Accuracy: A Cognitive Load Framework for Mapping the Capability Boundaries of Tool-use Agents
authors: Qihao Wang, Yue Hu, Mingzhe Lu, Jiayue Wu, Yanbing Liu, Yuanmin Tang
date: 2026-01-28
desc.: While LLMs' ability to use external tools enables powerful real-world applications, current benchmarks focus on final accuracy rather than revealing the cognitive bottlenecks that limit their true capabilities. This paper presents a framework based on Cognitive Load Theory that aims to decompose tasks into two components: Intrinsic Load and Extraneous Load. The paper discusses performance inconsistencies as cognitive load increases, and demonstrates how the proposed framework enables the identification of capability boundaries in the examined examples.
category: research

article: Build a Prompt Learning Loop - SallyAnn DeLucia & Fuad Ali, Arize
authors: AI Engineer, Sally Ann Delucia, Fuad Alli (Arize)
date: 2026-01-06
desc.: This talk aims to provide ideas on how it is possible to improve LLM responses by using feedback loops. It's important to view this talk through the lens of current research results regarding the LLM hallucination phenomenon and other factors. The main reason to keep current research results in mind is to avoid ending up in an infinite loop of failure/error.
category: youtube

article: Stanford CS230 | Autumn 2025 | Lecture 8: Agents, Prompts, and RAG
authors: Stanford Online
date: 2025-11-11
desc.: For more information about Stanford’s Artificial Intelligence professional and graduate programs
category: youtube, tutorial

article: Developer Experience in the Age of AI Coding Agents – Max Kanat-Alexander, Capital One
authors: AiEngineer, Max Kanat-Alexander
date: 2025-12-23
desc.: It feels like every two weeks, the world of software engineering is being turned on its head. Are there any principles we can rely on that will continue to hold true, and that can help us prepare for the future, no matter what happens? Max uses research, data, and his 20+ years working in enterprise Developer Experience teams to talk through what we can do now that will prepare us for an agentic future, no matter what that future holds.
category: youtube, opinion

article: Token-Guard: Towards Token-Level Hallucination Control via Self-Checking Decoding
authors: Yifan Zhu, Huiqiang Rong, Haoran Luo
date: 2026-01-29
desc.: Hallucination is a recognized phenomenon in the LLM field that impacts applications such as Retrieval-Augmented Generation (RAG) and Reward Modeling (RM). This paper introduces Token-Guard, a self-checking mechanism designed to identify and control hallucinations at the token level. The experiments demonstrate improvements.
category: research

article: Reward Models Inherit Value Biases from Pretraining
authors: Brian Christian, Jessica A. F. Thompson, Elle Michelle Yang, Vincent Adam, Hannah Rose Kirk and others (University of Oxford, University Pompeu Farba)
date: 2026-01-28
desc.: Despite their importance in LLM alignment, reward models (RMs) remain under-researched. This paper provides evidence that RMs inherit biases from their base models, suggesting that the choice of an open-source model is a reflection of values as much as performance. The paper discusses limitations of experiments and offers avenues for future research.
category: research

article: Professor Geoffrey Hinton - AI and Our Future
authors: City of Hobart, Geoffrey Hinton
date: 2026-01-08
desc.: Professor Geoffrey Hinton, known as the "Godfather of AI", will discuss artificial intelligence - how it works, the risks it poses to our society, and how we might coexist with super-intelligent AI. Ideal for business leaders, creatives, researchers, educators, students and anyone curious about the future of intelligence and society.
category: opinion

article: Your MCP Server is Bad (and you should feel bad) - Jeremiah Lowin, Prefect
authors: AI Engineer, Jeremiah Lowin
date: 2026-01-12
desc.: Too many MCP servers are simply glorified REST wrappers, regurgitating APIs that were designed for SDKs rather than agents. This leads to confused LLMs, wasted tokens, and demonstrably poor performance. If you have ever pointed an MCP generator at an OpenAPI spec and called it a day, this talk is your wake-up call.
category: youtube

article: Frontier Models & AI | Sam Altman, CEO & Co-Founder, OpenAI
authors: Cisco
date: 2026-02-04
desc.: Although Sam Altman, CEO and Co-Founder of @OpenAI, explores ideas about future possibilities and potential developments, he is asked during the interview to align his vision with the current state of research and existing technological capabilities. The interview, however, does not present clear data demonstrating how Codex outperforms alternatives or what 'better' specifically means in this context. The responses to questions may appear to be non-deterministic in nature. The interview relies heavily on thoughts about an "undefined future" that would require a deterministically defined foundation. It is interesting how the interview examined frontier AI models and their implications for economies, institutions, and global systems.
category: opinion

article: How to build secure and scalable remote MCP servers
authors: Den Delimarsky (Microsoft)
date: 2025-07-25
desc.: The tutorial provides insights into how to build a reliable Model Context Protocol (MCP) server, enabling AI agents to connect to external tools. It covers several crucial areas and provides valuable resources and ideas for tackling the challenge.
category: tutorial

The post JC-AI Newsletter #13 appeared first on foojay.

BoxLang 1.10.0: Functional Arrays, Elegant Loops & Distributed Locking

Cristobal Escobar — Wed, 04 Feb 2026 10:46:22 +0000

Table of Contents

What's New

Nine New Array Methods for Functional Programming
Elegant Loop Destructuring Syntax
Distributed Cache Locking for Clustered Environments
Dynamic Module Management

Performance Optimizations

Fully-Qualified Name Resolution
ASM Compilation Improvements
Streaming Binary Responses

Developer Experience Enhancements

MiniServer Warmup URLs
Runtime Introspection Variables
Module Binary Directory
JSR-223 Configuration Flexibility

Additional Improvements

Type System Enhancements
Cache Hierarchy
Date/Time Improvements
Query Component Enhancements
Oracle SQL Improvements

Notable Bug Fixes

Compilation & ASM
Class & Component System
Struct & Collection Handling
File & I/O Operations
HTTP & Networking
Compatibility Mode Fixes

Get Started

Download BoxLang 1.10.0:
Resources:
Thank You

We're excited to announce BoxLang 1.10.0, a feature-packed release that brings powerful functional programming capabilities, elegant loop syntax, and enterprise-grade distributed locking to the BoxLang runtime. This release represents a significant leap forward in developer productivity and application scalability.

🎯 What's New

Nine New Array Methods for Functional Programming

BoxLang 1.10.0 introduces nine powerful array methods that bring modern functional programming patterns to your collections. These methods enable cleaner, more expressive code while reducing the need for verbose iteration patterns.

Data Chunking for Pagination
Split arrays into manageable chunks - perfect for pagination, batch processing, or UI rendering:

items = [ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ]
pages = items.chunk( 3 )
// Result: [ [1,2,3], [4,5,6], [7,8,9], [10] ]

// Real-world pagination
products = productService.getAllProducts()
productPages = products.chunk( 20 )
productPages.each( ( page, index ) => {
    println( "Page #index# contains #page.len()# products" )
} )

Smart Element Finding with Defaults
The new findFirst() and first() methods eliminate null-checking boilerplate by supporting default values:

users = [
    { name: "Alice", role: "user" },
    { name: "Bob", role: "admin" },
    { name: "Charlie", role: "user" }
]

// Find with default fallback
admin = users.findFirst( 
    ( u ) => u.role == "admin",
    { name: "Guest", role: "guest" }
)

// Safe first element access
settings = configArray.first( { theme: "default", locale: "en" } )

Data Grouping and Aggregation
The groupBy() method transforms arrays into grouped structures using either property keys or custom functions:

// Group by property
transactions = [
    { id: 1, category: "food", amount: 45.20 },
    { id: 2, category: "transport", amount: 12.50 },
    { id: 3, category: "food", amount: 28.75 }
]

byCategory = transactions.groupBy( "category" )
// Result: {
//   food: [ {...}, {...} ],
//   transport: [ {...} ]
// }

// Group by custom logic
bySizeCategory = transactions.groupBy( ( t ) => {
    return t.amount > 100 ? "large" : t.amount > 50 ? "medium" : "small"
} )

Flatten Nested Structures
Control how deep to flatten nested arrays with the new flatten() method:

nested = [ [1, [2, 3]], [4, [5, [6]]] ]

nested.flatten()      // [1, 2, 3, 4, 5, 6] - fully flattened
nested.flatten( 1 )   // [1, [2, 3], 4, [5, [6]]] - one level only
nested.flatten( 2 )   // [1, 2, 3, 4, 5, [6]] - two levels

// Real-world: flatten API response structures
apiResults = [
    { items: [ {id: 1}, {id: 2} ] },
    { items: [ {id: 3}, {id: 4} ] }
]
allItems = apiResults.map( ( r ) => r.items ).flatten()

Map and Flatten in One Operation
The flatMap() method combines mapping and flattening - essential for working with nested data structures:

orders = [
    { orderId: 1, items: [ "A", "B" ] },
    { orderId: 2, items: [ "C", "D", "E" ] }
]

// Extract and flatten all items
allItems = orders.flatMap( ( order ) => order.items )
// Result: [ "A", "B", "C", "D", "E" ]

// vs. the verbose alternative:
allItems = orders.map( ( order ) => order.items ).flatten()

Filter Inverse with Reject
The reject() method provides the inverse of filter(), making exclusion logic more readable:

products = [
    { name: "Laptop", inStock: true },
    { name: "Mouse", inStock: false },
    { name: "Keyboard", inStock: true }
]

// More readable than filter with negation
outOfStock = products.reject( ( p ) => p.inStock )

// vs. the filter equivalent
outOfStock = products.filter( ( p ) => !p.inStock )

Matrix Operations with Transpose
Convert rows to columns in 2D arrays - essential for data analysis and matrix operations:

matrix = [
    [ 1, 2, 3 ],
    [ 4, 5, 6 ]
]

transposed = matrix.transpose()
// Result: [ [1, 4], [2, 5], [3, 6] ]

// Real-world: reorganize tabular data
salesData = [
    [ "Q1", 1000, 1200, 900 ],
    [ "Q2", 1100, 1300, 950 ]
]
byMonth = salesData.transpose()
// Now organized by columns instead of rows

Remove Duplicates with Type Control
The unique() method removes duplicate values with optional type comparison:

numbers = [ 1, 2, 2, 3, 1, 4, 3 ]
numbers.unique()  // [ 1, 2, 3, 4 ]

// Type-aware uniqueness
mixed = [ 1, "1", 2, "2", 1 ]
mixed.unique()        // [ 1, "1", 2, "2" ] - preserves types
mixed.unique( "any" ) // [ 1, 2 ] - type-insensitive

Combine Arrays Element-wise with Zip
The zip() method combines multiple arrays element-by-element, perfect for correlating related datasets:

names = [ "Alice", "Bob", "Charlie" ]
ages = [ 25, 30, 35 ]
cities = [ "NYC", "LA", "Chicago" ]

combined = names.zip( ages, cities )
// Result: [
//   [ "Alice", 25, "NYC" ],
//   [ "Bob", 30, "LA" ],
//   [ "Charlie", 35, "Chicago" ]
// ]

// Real-world: combine headers with data
headers = [ "Name", "Email", "Role" ]
values = [ "Alice", "alice@example.com", "Admin" ]
record = headers.zip( values )

Elegant Loop Destructuring Syntax

BoxLang 1.10.0 introduces destructuring syntax for for loops, eliminating verbose iteration patterns:

// Struct iteration with key and value
userData = {
    name: "Alice",
    email: "alice@example.com",
    role: "admin"
}

for ( key, value in userData ) {
    println( "#key#: #value#" )
}

// Array iteration with item and index
colors = [ "red", "green", "blue" ]
for ( color, index in colors ) {
    println( "Color #index#: #color#" )
}

// Query iteration
for ( row, rowNumber in getUserQuery() ) {
    println( "Processing user #row.name# (row #rowNumber#)" )
}

This new syntax replaces verbose patterns like structEach() and manual index tracking:

// Old verbose approach
userData.each( ( key, value ) => {
    println( "#key#: #value#" )
} )

// New clean syntax
for ( key, value in userData ) {
    println( "#key#: #value#" )
}

Distributed Cache Locking for Clustered Environments

The lock component now integrates with cache providers implementing the ILockableCacheProvider interface, enabling distributed locking across multiple servers without external coordination systems.

// Distributed lock across all servers in cluster
lock( name="processPayment", cache="redisCache", timeout=30 ) {
    // Critical section protected cluster-wide
    payment = paymentGateway.charge( orderId )
    updateInventory( orderId )
    sendConfirmationEmail( orderId )
}

// Traditional local lock still available
lock( name="updateLocalCache", type="exclusive", timeout=10 ) {
    localCache.update( key, value )
}

Requirements: Distributed locking requires a cache provider that implements ILockableCacheProvider. Compatible providers include:

bx-redis - Redis-backed distributed locking
bx-couchbase - Couchbase distributed locks
Custom cache providers implementing the locking interface
Standard BoxLang caches and the default cache implementation do not support distributed locking.

Dynamic Module Management

New module loading methods enable runtime module management, perfect for plugin architectures and dynamic extensions:

moduleService = getModuleService()

// Load a single module at runtime
moduleService.loadModule( expandPath( "/plugins/customAuth" ) )

// Load all modules from a directory
moduleService.loadModules( expandPath( "/extensions" ) )

// Check module status
if ( moduleService.hasModule( "customAuth" ) ) {
    settings = moduleService.getModuleSettings( "customAuth" )
    println( "Custom auth enabled: #settings.enabled#" )
}

This is especially valuable for:

Plugin systems - Load user-installed plugins dynamically
Feature flags - Enable/disable modules based on configuration
Java integration - Allow Java applications to extend BoxLang functionality at runtime

⚡ Performance Optimizations

Fully-Qualified Name Resolution

Significant optimizations to fully-qualified name (FQN) resolution improve class loading and component instantiation performance. Applications with heavy component usage will see noticeable improvements in startup time and runtime performance.

ASM Compilation Improvements

The ASM compiler now handles large methods with try/catch blocks more efficiently through improved method splitting. This reduces bytecode size and improves compilation speed for complex business logic.

Streaming Binary Responses

The content component now uses chunked transfer encoding for binary responses instead of buffering the entire response in memory. This reduces memory pressure and improves performance for large file downloads, PDF generation, and image serving.

// Efficiently stream large PDFs without memory buffering
content( type="application/pdf" ) {
    writeOutput( generateLargePDF() ) // Now streams in chunks
}

🛠️ Developer Experience Enhancements

MiniServer Warmup URLs

The MiniServer runtime now supports warmup URLs to pre-initialize your application before serving production traffic:

{
  "warmupURLs": [
    "http://localhost:8080/api/health",
    "http://localhost:8080/admin/cache/prime",
    "http://localhost:8080/database/connect"
  ],
  "web": {
    "http": {
      "enable": true,
      "port": 8080
    }
  }
}

Warmup requests execute sequentially during server startup, ensuring:

Caches are populated
Database connections are established
Critical initialization is complete
The application is fully ready before accepting requests

Runtime Introspection Variables

Two new server scope variables aid debugging and runtime identification:

// Get the Java process ID
println( "Running on PID: #server.java.pid#" )

// Identify active compiler (ASM, Java, or Noop)
println( "Using compiler: #server.boxlang.compiler#" )

These variables are invaluable for:

Container deployments - Identifying processes in Kubernetes/Docker
Performance profiling - Connecting to the correct JVM for profiling tools
Debugging - Understanding which compilation strategy is active

Module Binary Directory

BoxLang now creates a bin/ folder in the BoxLang home directory, preparing for future CommandBox integration where modules can provide CLI commands and executables:

~/.boxlang/
  └── bin/
      ├── module-cli-tool
      └── custom-command

JSR-223 Configuration Flexibility

The JSR-223 scripting engine integration now supports environment variables and system properties for configuration, enabling containerized deployments:

# Environment variable configuration
export BOX_JSR223_TIMEOUT=30000
export BOX_JSR223_ENABLE_LOGGING=true

# System property configuration
java -Dboxlang.jsr223.timeout=30000 \
     -Dboxlang.jsr223.enableLogging=true \
     -jar app.jar

🔧 Additional Improvements

Type System Enhancements

Numeric Casting - General numeric casting now truncates by default for consistent behavior across integer conversions
- Set Length Support - The len() function now works on java.util.Set collections
- BigDecimal/Long Support - formatBaseN() now properly handles java.lang.Long types

Cache Hierarchy

The cache retrieval system now properly follows the context cache hierarchy:

// Application cache takes precedence over global cache
cache( "userSessions" )  // Checks app cache first, then global

// Explicit cache provider targeting
cacheGet( "key", "redisCache" )  // Direct provider access

This ensures application-level cache isolation while maintaining fallback to global caches.

Date/Time Improvements

New date mask support: "January, 05 2026 17:39: 13 -0600" format
Fixed date equality issues in compatibility mode with different timezones
Resolved false being incorrectly cast to DateTime objects in compat mode

Query Component Enhancements

// Columns now accept arrays
query = queryNew( [ "id", "name", "email" ] )

// Relaxed dbtype validation for better CFML compatibility
query = new Query()
query.setDatasource( "myDB" )
query.setSQL( "SELECT * FROM users" )

Oracle SQL Improvements

The runtime now automatically removes trailing semicolons from Oracle SQL statements, eliminating common syntax errors.

🐛 Notable Bug Fixes

Compilation & ASM

[BL-1505] Reworked splitting of large methods in ASM compiler
[BL-2017] Fixed ASM compilation failure with closures inside ternary expressions
[BL-2094] Fixed double transpilation in string replace operations with nocase flag
[BL-2141] Resolved parser issue with text operator between two interpolated variables

Class & Component System
[BL-2059] Fixed inheritance at three levels losing variables scope when functions assigned as variables
[BL-2110] Resolved error calling pseudo constructor when using getClassMetadata()
[BL-2117] Fixed missing metadata annotations on abstract UDFs
[BL-2119] Interface errors when implementing class doesn't set defaults that interface specifies
[BL-2121] Injected UDFs now have correct "current" template reference
[BL-2122] UDF called from thread inside class no longer loses class reference

Struct & Collection Handling
[BL-2138] Fixed struct assignment creating string keys instead of integer keys
[BL-2142] Resolved string hash collisions in structs causing key conflicts

File & I/O Operations
[BL-2095] File member methods no longer incorrectly accessible on java.io.File instances
[BL-2096] getCanonicalPath() now preserves trailing slash on directories
[BL-2118] Fixed directoryCopy() mishandling trailing slashes
[BL-2124] Compat mode directoryCopy() now overwrites by default for CFML compatibility

HTTP & Networking
[BL-2081] Fixed HTTP timeout error with BigDecimal to Integer casting
[BL-2098] HTTP component no longer fails when empty string passed for proxy server
[BL-2105] Resolved duplicate cookies being set with different paths

Compatibility Mode Fixes
[BL-1917] Fixed urlEncodedFormat() differences from Lucee/ACF
[BL-2079] Regression fix for date equality with different timezones
[BL-2088] Compat cache BIFs now properly use context cache retrieval hierarchy
[BL-2091] Timeout attribute is now optional on lock tag in Lucee compat mode
[BL-2129] Variable attribute is now optional on execute component in compat mode
[BL-2131] Compat mode now allows duplicate UDF declarations in CF source files

🚀 Get Started

Download BoxLang 1.10.0:

BoxLang Runtime
VS Code Extension

Resources:

Documentation
GitHub Repository
Community Discord

🙏 Thank You

BoxLang 1.10.0 represents contributions from our amazing community, enterprise customers, and the Ortus Solutions team. Special thanks to everyone who reported issues, tested features, and provided feedback.

We're excited to see what you build with BoxLang 1.10.0!

The post BoxLang 1.10.0: Functional Arrays, Elegant Loops & Distributed Locking appeared first on foojay.

Enterprise Java in Practice: Fragmentation, Platforms and Real-World Trade-offs

Chiara Civardi — Thu, 29 Jan 2026 10:11:40 +0000

Table of Contents

Where fragmentation shows upWhy platform architecture mattersJoin our webinar: Insights on Enterprise Java, Trends, Challenges and StrategiesExplore the data

Enterprise Java has matured into one of the most stable and widely adopted ecosystems in software development. Yet for many teams, the biggest challenges no longer come from the language itself, but from the complexity of the environments built around it.

Modern enterprise Java teams are dealing with a mix of legacy Java EE applications, Jakarta EE runtimes, microservices, container platforms, cloud-native deployments, and increasingly sophisticated DevOps pipelines. The result is an ecosystem that is powerful, but often fragmented across frameworks, runtimes, tooling, and operational models.

To understand how organizations are navigating these challenges, at Payara we surveyed enterprise Java practitioners and analyzed the results in the State of Contemporary Enterprise Java Report (download here). The findings highlight a clear pattern: while Java remains a core enterprise technology, fragmentation across platforms and workflows is becoming a key bottleneck for productivity, reliability and scalability.

Where fragmentation shows up

In real-world enterprise environments, fragmentation typically emerges across several layers:

runtime platforms and application servers
frameworks and libraries across teams and projects
deployment models (VMs, containers, Kubernetes, hybrid cloud)
configuration and environment management
observability, logging, and monitoring stacks
CI/CD pipelines and operational automation

Even when individual components are best-in-class, integration overhead and operational inconsistency increase cognitive load for developers and platform teams.

Why platform architecture matters

Platform choices directly influence how teams manage complexity. A well-designed enterprise Java platform can:

standardize runtime behavior across environments
reduce custom scripting and glue code
simplify deployment models across cloud and on-premise
improve developer experience through consistent tooling
align application architecture with modern DevOps practices

The report shows growing interest in platforms that provide cohesive runtime, automation, and operational consistency, rather than isolated tools.

Join our webinar: Insights on Enterprise Java, Trends, Challenges and Strategies

On Wednesday, Feb 11, 2026 at 2:30 PM GMT, register here , Payara experts will present a technical breakdown of the report findings in the live session Insights on Enterprise Java: Current Trends, Challenges and Strategies.

The webinar will cover:

how teams are modernizing Java EE and Jakarta EE applications
architectural patterns emerging in enterprise Java deployments
Kubernetes adoption and its impact on Java workloads
DevOps maturity across enterprise Java teams
common failure points and scalability constraints
practical strategies for reducing fragmentation

We will also connect survey data to middleware architecture, showing how platform design decisions affect deployment, performance, operability, and developer productivity.

Explore the data

The State of Contemporary Enterprise Java Report provides detailed survey data, technical insights, and analysis of enterprise Java trends across industries. If you are responsible for designing, building, or operating Java systems at scale, the report offers a data-driven perspective on where teams are succeeding, where they struggle, and what architectural choices matter most.

Register for the webinar to explore the findings with Payara engineers, and dive into the report to benchmark your own enterprise Java stack against current industry patterns.

The post Enterprise Java in Practice: Fragmentation, Platforms and Real-World Trade-offs appeared first on foojay.

Not a Lucid Web3 Dream Anymore: x402, ERC-8004, A2A, and The Next Wave of AI Commerce

Michal Maléř — Fri, 09 Jan 2026 16:05:58 +0000

Table of Contents

Vocabulary for this article

ForewordPart 1 - Bringing companies on-chain with x402Part 2- Introduction: Beyond Ads and Subscriptions: Agent Commerce on x402 and ERC-8004Part 3 - Tech that will change the internet

Agent commerce, x402, and ERC-8004: from ad-funded web to paid APIs

Part 4 - DayDreams.Systems: an x402 / 8004 implementation example

How DayDreams structures the stack
Lucid as an abstraction over AP2, A2A, x402, and 8004
What kinds of agents is Lucid designed for
Lucid Agents: BYO framework with x402 and 8004 baked in
Reliability and Router v2: from per-request to balance-based flows
From SEO to AEO: optimizing for agents instead of humans
Privacy, z402, and Starknet
Where the value in x402 is likely to appear
Macro backdrop and current stage
Conclusion

This article is for technically savvy readers, especially developers, protocol designers, and product teams working with AI agents, APIs, or crypto rails, who want a clear view of how these areas connect.
It explains how x402, ERC-8004, and agent discovery layers turn APIs and agents into small usage-based businesses, and what that means for real systems over the next 1–3 years.

Vocabulary for this article

In this article, I use the term micro business for a very small overall business, and nano business for a single x402-priced endpoint or agent that earns on its own from per-call payments in stablecoins.

AP2 (Agent Payment Protocol): AP2 defines how agents pay each other. It standardizes how a service quotes a price, how payment is confirmed, and how both sides record what was bought, so payments fit directly into automated agent workflows. In practice, it is a protocol that lets one machine pay another machine for work, without a human in the loop.

A2A (Agent-to-Agent communication): A2A covers how agents talk, pass context, and coordinate work. It lets agents call each other, exchange structured messages, and chain tasks instead of acting as isolated scripts.

x402: x402 is an HTTP-based payment protocol for APIs. A server responds with status 402 Payment Required, the price, and a payment route, and the client pays by using stablecoins on-chain and then retries the request to get the result.

ERC-8004 (8004): ERC-8004 standard is an on-chain registry for agents. It gives each agent an identity and a place to store reputation data, so other agents and tools can decide whom to trust and which services to call.

Foreword

x402 and ERC-8004.
Standards for on-chain payments and identity for agent operation.

Most people have never heard of these standards, and even many crypto natives only see the surface of the agent narrative.
Behind them is a simple idea.
Agents can pay and get paid through tiny on-chain transactions, and in return, they can handle tasks that would be impossible to scale by hand.

We are still early in this emerging space, but I suspect everything will evolve much faster than most people expect.
One of the drivers for this is the push to build an agent-driven internet.
Another is the need to improve privacy on the processes we already use.

For example, Vitalik Buterin has already highlighted the need for privacy-preserving x402 payments. Every time an agent pays an endpoint, it leaks what service it used, when it used it, how often it used it, and sometimes even the rough size or type of job.
Competitors can see which APIs your app or agent relies on.
Data brokers can reconstruct user behavior and business logic from payment flows.
Over time, you get a giant, searchable map of who pays whom for what.

For human users, this is a privacy nightmare.
For agents as businesses, it is also an alpha leak.

Agents can do a lot of useful work for you, but privacy-preserving payments are one of the first problems to solve.
A development team I use as an example is currently building private x402 transactions on the Starknet stack, also known as z402.
When this layer is in place, it opens the door to hundreds of use cases. If you read further, you’ll learn more about some of these.

I will first explain where the web is today and why agents break the old ad-and-subscription model.
I will also introduce the basic terms you need to understand to get the most from this reading.
Then, I will show how standards such as x402 and ERC-8004 give agents a way to pay and prove value.
Finally, I will look at an example development team, DayDreams.Systems, that builds on top of these standards.

The goal is not to promote any specific team, but to show why this kind of plumbing is likely to matter if the agent economy becomes real.

Part 1 - Bringing companies on-chain with x402

Today, most x402 experiments start with crypto-native builders, but the long-term impact sits with traditional companies.
x402 runs on familiar Web2 infrastructure yet settles in stablecoins on-chain, so it integrates directly with existing usage-based billing.
Enterprises already use metered APIs and issue monthly invoices.
If an endpoint can expose “this call costs 0.2 cents in USDC” over HTTP 402, finance teams can reconcile that flow the same way they handle cloud or SaaS costs.

In other words, x402 does not ask companies to change how they think about software.
It only changes the rail that moves the money.
x402 sits where Web2 companies already live: HTTP, APIs, usage billing, and stablecoins instead of card networks.
That is also why I think it is important to be clear about what x402 is not.
It is not a token sale, and it is not a speculative asset.
It is a payment protocol.
Or, as people in payments, fintech, and crypto might say, a “payment rail.”

From my point of view, and from how builders in the blockchain space talk about it, x402 is a way to quickly enable micropayments across the internet and to let traditional companies become meaningfully on-chain without having to rebrand themselves as “crypto projects.”

Once you look at the user base numbers, the potential becomes clearer.
Today, there are about 40–50 million weekly active crypto users.
By comparison, roughly 900 million people already use ChatGPT-class applications.
That is almost 20 times as many people as the entire active crypto base.
Now imagine a large interface, such as ChatGPT or a similar agent front-end, that increasingly relies on external APIs, which themselves expose prices in x402.
Instead of keeping all those upstream costs hidden as an internal line item, it could settle a part of them directly on-chain, in stablecoins, on the same standard that those providers use.
This would make it easier to share revenue with third-party services, give users or their own agents the option to pay directly for some calls, and reduce the need for custom billing integrations with every partner.

If a setup like that becomes common, you are no longer talking about thousands of transactions per day.
You are looking at billions of very small events, each representing a paid unit of compute or data.
Traditional card networks and ad-funded models are not designed for this pattern.
They expect fewer, larger payments, not billions of sub-cent charges between machines.

Card systems also assume a human at the end of the flow and a checkout-style experience.
Agent payments look different. They happen in the background, often in bursts of many tiny calls, with prices that can depend on context, volume, or conditional rules. This is the type of workload where stablecoin rails and an HTTP-native protocol, such as x402, fit better than card fees and monthly billing cycles. Card systems also do not expose a simple, machine-readable way for one service to quote a price per call and another service to pay it automatically.

x402 is designed to fill exactly this gap.
It keeps the familiar HTTP request-and-response model, attaches a stablecoin price to each call, and settles that price on-chain as a tiny, usage-based payment.
At the scale where agent traffic lives, that kind of payment protocol can handle the granularity that existing payment infrastructure struggles with.
Agent payments tend to be high-volume, high-velocity, and low-value, often conditional and composable across many services, which fit stablecoin rails much better than card networks.

Once you take that volume and this direction of travel seriously, another question appears.
What if the large incumbents simply ignore x402 and keep everything inside their own billing systems? Well, they cannot remove x402 endpoints from the internet, but they can decide which payment flows they support in their own products.
The counterpoint is that x402 does not need permission from any single platform.
It rides on plain HTTP, so any agent, SDK, or “agent browser” can call an x402 endpoint and pay it.
If x402 endpoints become a good source of useful data or computing, it is cheaper for big companies to talk to them than to rebuild every useful resource in-house.
If they refuse to interoperate, that creates an opening for other tools, wallets, and agent clients that do.
In that sense, x402 is less about convincing one company to flip a switch and more about giving the rest of the ecosystem a standard that works even if incumbents are slow to join.

From this perspective, when people talk about “bringing companies on-chain,” the focus is not on tokenizing balance sheets or putting shares on a ledger.
It shifts to something more mundane and more powerful: moving the billing layer for everyday AI APIs and SaaS endpoints onto x402, so the internet can support billions of sub-cent payments per day without collapsing under its own business model.

Part 2- Introduction: Beyond Ads and Subscriptions: Agent Commerce on x402 and ERC-8004

Imagine you run a website with real value.
A research blog. A niche data feed. A book you provide for free.
A long form guide that took you nights and weekends to write.

Today, the way you “monetize” that work is simple.
You paste in ad scripts and hope that human eyeballs show up.
Meanwhile, bots and AI agents crawl your pages on the code level, scrape the raw content, feed it into their pipelines, and never pay you a cent.
Your ads load.
Your layout renders.
Your analytics register another “visit.”
But the real consumer is a headless agent that does not care about banners or pop-ups.

You carry the hosting cost.
You carry the bandwidth cost.
The agent walks away with the value.

Over time, this turns into a more general “pay-per-crawl” pattern.
Most traffic on the web comes from automated clients, not humans in a browser, so it makes sense that machines, not people, become the primary payers at the protocol level.

Now imagine a different setup.
Your content sits behind a tiny paywall that understands x402.
When a human or an AI agent wants your data, they do not see ads. They see a 402 “Payment Required” response with clear, machine-readable terms. Their client or agent calls you with a wallet that already holds a small stablecoin balance, and that the user has authorized to spend on their behalf.
The agent pays a fraction of a cent from that balance, and then gets the data.
A human user still tops up that balance from time to time, by card, bank transfer, or a normal on-ramp, but each individual call is handled automatically by the software, not by clicking a “Pay” button on every request. In the background, a programmable wallet enforces the rules you set. You can cap how much an agent spends per day, restrict which endpoints it can pay, and keep an audit trail of every call.

The agent does the micro-payments, but the human still defines the policy and funding source.
No accounts.

No OAuth.
No email capture funnels.

On your side, you do not babysit API keys.
You do not fight an endless war against scrapers.
You run an agent of your own that guards the data, negotiates access, and sells it on your behalf.
With ERC-8004, that agent has a verifiable identity and a reputation record on the chain, so other agents know who they are talking to and whether they can trust the stream it serves.

The flow flips.
Your “scraping victim” website becomes a nano business in an agent economy.

But wait a second.
There is also a “light side of the moon” to it.

Agents can:

Act as matchmakers between your content and the right readers, just as you do when you share your work on social media.
Provide personalized entry points and automated follow-ups for people who enjoy your work, and help distribute it to the right corners of the internet.
Monitor the health of your content by tracking which parts of your article trigger refunds, fast bounces, or never lead to any follow-up actions.
Act as quality filters and bring you only the material that matches your preferences.
Handle access control by managing who gets which tier of content, which parts are free, and which are pay-per-read.
Check sponsorship offers against your ethical guidelines and pricing, and place small, relevant sponsorships in your content feed on your terms.
Provide cross-format delivery by generating a short audio version, a bullet-point version, or a “for founders” version of the same content, and offer them as micro-upgrades.
Let the reader’s agent choose the format that the person prefers.
And, in the long run, pay for their own existence by earning more from their work than they spend on data, compute, and tools.
Control permissionless money and use payments to influence humans, other agents, and software systems.

Now, think about how we use search today.
Every Google query consumes CPU, memory, network bandwidth, and energy.
It costs real resources every time you type a word and hit Enter.
You never see the bill, because Google decided long ago that you are not the customer.
The advertiser is.
To make that work, Google sells access to its index.
Sponsored links buy their way to the top.
The first result is often not the best answer for you.
It is the answer that won an auction.

Now project that forward into an agentic internet.
Instead of one giant search engine that hides costs behind ads, you have a search agent that works only for you.
You pay it directly in crypto by using x402 for the time and data it spends on your query.
It fans out your request to many data providers, each with their own x402 paywall, and picks the best mix of price and quality.
The results it returns are not sponsored.
They reflect what your agent actually believes is the best answer under your constraints.

Again, ERC-8004 matters here.
Your search agent needs to decide which other agents and services to trust.
Identity, reputation, and validation registries give it a way to see who has delivered good results in the past and who has a track record of spam or low-quality work.
Instead of SEO games and ad auctions, you get a market where agents rank each other on the basis of verifiable work and real payments.

Once you have x402 for payments and ERC-8004 for identity and reputation, many of the broken parts of today’s internet start to look fixable.

API billing becomes less painful.
Right now, if you run an API, you set up subscriptions, rate limits, or custom contracts.
You over-provision for big customers and under-serve the long tail.
With x402, any API endpoint can publish a price per call, down to fractions of a cent, and accept stablecoins over HTTP 402 without accounts or manual invoicing.
Agents and apps pay exactly for what they use, and nothing else.

Spam becomes more expensive.
In Web2, bots can hammer your endpoints for free until you give up and put everything behind API keys, CAPTCHAs, or hard gating.
In an x402 world, every request costs something, even if it is tiny.
Attackers cannot spray infinite traffic without burning real money.
Legitimate users still pay far less than a typical subscription, and they do not have to fight your protection layers.

Agent discovery becomes less biased.
If discovery engines sit on top of x402 and ERC-8004, they can rank services not just by who shouts the loudest, but by who other high-reputation agents actually pay and use.
Payment flows become a kind of “vote” that reflects real economic trust, not vanity metrics or bought traffic.

Multi-agent workflows become less fragile.
Protocols like A2A or MCP define how agents communicate with each other.
ERC-8004 anchors who they are and why you might trust them.
x402 gives them a way to settle up after each call.
Speak.
Prove.
Pay.
The protocol stack is starting to align with what a real economy needs.

And all of this happens without throwing the web away.
HTTP stays.
APIs stay.
We just finally light up the status code that has been reserved for three decades and connect it to a global ledger.
We give agents a passport and a credit line, and we tell them:
“If you want to use the internet’s value, you pay the people who create it.”

That is the gap that x402 and ERC-8004 try to close.
They do not promise magic.
They take two simple ideas that the speakers in the DayDreams X Space kept coming back to:
Payment should be as native as a GET request.
Trust should be as inspectable as a transaction.

In the agent economy that I want to see, agents do not only take. They also bring.
My own agent can guard my content behind x402, speak ERC-8004 so other agents know who they deal with, and recommend my work to readers who are likely to value it.

Other agents can work on behalf of readers, scan paid endpoints, and decide that my article is worth a fraction of a cent. The same technology that crawls and copies can also route new readers to my work, pay for it, and feed back a signal about what actually helps people.

For twenty years, the web asked one main question: “Does this look good to a human on a screen?”

We obsessed over templates, CSS, copy, and SEO so that a landing page both looked good and ranked well.
In the agent era, the question changes, and the question changes the angle to this:

“Can an agent reach your value through a clean API, pay for it over x402, and know from ERC-8004 who it is dealing with?”

Sites and services that answer yes to that question still care about UX and SEO, but they do not depend on fancy landing pages to survive.
They have something stronger.
They have a business model and an interface that speaks the native language of the new internet: agents, APIs, and fine-grained payments.

Part 3 - Tech that will change the internet

Agent commerce, x402, and ERC-8004: from ad-funded web to paid APIs

Where we are now: ads, subscriptions, and hard-coded APIs

Let us take a closer look at the current state of the online experience.

Most online products still rely on two basic business models.
Ads pay for “free” content, and subscriptions bundle access into monthly or yearly plans.

This works poorly for today’s AI-driven internet.

AI agents can ignore ads.
Subscriptions are too coarse when you only need a few calls or a small amount of data.
APIs deliver real value, but there is no standard way to charge per-call at internet scale.

On the technical side, most AI systems still look like this:

An app or agent uses a set of APIs with manually managed API keys.
Workflows are hard-coded by humans.
Payments are processed through separate Web2 billing systems, such as Stripe dashboards, custom invoices, or prepaid credits.
Access often lives in walled gardens rather than on open, shared rails.

This setup has some clear limitations.

Agents cannot easily discover new services on their own.
There is no standard payment flow for machine-to-machine calls.
Each integration is custom, slow to build, and hard to replace.
Abuse and scraping are common because there is no built-in economic cost per call.

At the same time, demand for AI and APIs is exploding.

There are roughly tens of millions of weekly crypto users.
Hundreds of millions of users interact with ChatGPT-class apps.

We are in “the API era.”
The web serves more APIs than static pages, yet the payment and access layer still behaves like the early web.

What needs to change for agent commerce to work?

AI is moving from answering questions to taking actions.

Agents do not just chat.
They:

Call APIs to fetch data and context.
Reserve and manage cloud resources.
Trigger workflows across services.
Compose multiple tools to solve a task end-to-end.

To support this, we need the following three:

1. A standard payment primitive for APIs and agents, such as x402.

2. A discovery and identity layer so agents can find and rank services, which in the Ethereum ecosystem maps to ERC-8004 agent registries.

3. A business layer so individuals and teams can turn endpoints into small, efficient businesses.

Today, the missing piece is often payment and discovery.

Agents do not have a native way to pay per call.
Providers cannot expose tiny, nano-sized services in a simple, open way.
Developers do not know where to list endpoints or how to reach users beyond their own app.

This blocks a more granular and open market where:

A weather API can charge a fraction of a cent per call.
A niche dataset can charge per query instead of per month.
A small tool can be a nano business that you set up in 30 minutes and leave running.

Without a standard, every project reinvents billing and access.
That slows the market and keeps power in a few large platforms.

Current bottlenecks: walled gardens, spam, mispriced data

The web stack of today suffers from being built on the code infrastructure of yesteryear.

1. Walled gardens and private workflows

Workflows are private and hard-coded.
API keys are stored and managed by humans.
Agents cannot explore new services freely because access is gated by opaque contracts, custom dashboards, or per-vendor keys.

Result:
Innovation is locked inside platforms instead of happening on neutral rails.

2. No standard way for agents to pay

Agents need to pay for:

Data.
Compute.
Models and inference.
Specialized tools and services.

However, there is currently no common payment layer for agents.

Providers handle billing off-chain.
Calls might be free until rate limits hit, then “contact sales.”
There is no portable, machine-readable way to say “this endpoint costs X per call.”

This prevents a real microservice economy between agents.

3. Broken pricing models for content and data

Valuable sites and datasets are scraped for free.
Ads do not work well when agents are the consumers.
Subscriptions do not fit small, rare, or niche usage.

There is no good way to price:

A single clean Polymarket signal.
A specialized dataset query.
One high-value article read by an agent.

The result is either under-monetization or overly heavy paywalls.

4. Spam and free riding

APIs are often hit by bots and abusive traffic.

Without a built-in cost per call, spam is cheap.
Providers add complex rate limits, CAPTCHAs, and manual approvals.
This hurts honest developers and makes APIs harder to use.

5. Distribution and discoverability

Builders do not know:

Where to list x402-style endpoints.
How agents will find them.
How to rank providers when many offer similar services.

The coming evolution phase is comparable to the early web.

Search engines became the gateway for websites.
Here, agent discovery engines and agent stores will serve as the gateway.

However, without standards, these discovery layers risk becoming new silos.

How x402 solves per-call payments and spam

Let me present now a clear “cause → solution → fix” structure around x402 that will need to be developed.

x402 in short:

Uses HTTP status 402 Payment Required.
- Note: The HTTP 402 Payment Required code has existed in the spec since the early web, but it never had a practical implementation until standards such as x402 defined how to attach a real payment flow to it.
Let's have a server reply with “you must pay X in asset Y” in a machine-readable way.
Let a client (human app or agent) pay by using stablecoins on a supported chain.
After payment, the server returns the result.

This has several important properties.

It fits directly into existing HTTP flows.
Web2 developers already understand status codes and retries.
Developers only need a wallet adapter and payment handler, not a full Web3 stack.
For them, it feels closer to adding Stripe than building a dApp.

How x402 fixes the issues

Standard per-call payments

Each endpoint can publish a clear price per call.
Agents and apps can:
- Discover the endpoint.
- Receive a 402 with pricing terms.
- Pay and get the result.
  
  This turns any useful resource into a nano business.
Better pricing models

x402 supports:
- Per-call pricing.
- Very small payments, even fractions of a cent.
- Flexible models for data, content, and compute.
  
  This aligns well with AI and API cost structures, which are naturally usage-based.
Spam resistance

Every call has a cost.
Bots and abusive patterns become expensive to run.
x402 serves as both a security primitive and a payment rail.
Open and chain-agnostic design

x402 stays open and does not lock anyone to a single vendor.
Different chains and infrastructure providers can implement it.
Any wallet that speaks x402 can pay any endpoint that speaks x402.
On-ramp for traditional companies

Enterprises already use usage-based billing, and stablecoins are easier to explain than volatile tokens.
x402 lets them reuse:
- HTTP.
- Usage invoices.
- Stable settlement rails.
  
  This lowers their barrier to on-chain adoption.

Why ERC-8004 is as important as x402

Payment is not enough.
Agents also need to decide who to call.

We now need to link x402 to an identity and reputation layer, concretely to the ERC-8004 standard for agent registries. ERC-8004 lets agents anchor identity, reputation, and verification data on-chain. Together, x402 and ERC-8004 give agents a way to both pay for services and trust the services they choose.

Key points:

Agents register with an on-chain identity.
Reputation and performance metrics link to that identity.
Orchestration engines can pick among providers based on trust signals, not only price.

This enables:

Trusted agent-to-agent commerce, where an agent can justify why it chose a given provider.
Composable orchestration, where workflows route traffic to high-reputation endpoints.
Open discovery, where search and agent stores can index resources on neutral infrastructure instead of closed catalogs.

Together, x402 and ERC-8004 create:

A payment primitive for APIs and agents.
A discovery-and-trust primitive that sits above it.

This is the foundation for an open agent-commerce stack.
On top of the stack, we can now add concrete tools, many of which are already in development.
Let's get down to business.

DayDreams.Systems: turning the stack into real tools and businesses

As an example of tooling that builds upon the x402 and ERC-8004 stack, let us take a look at the DayDreams.Systems project.

The work of the DayDreams team mainly focuses on the following 3 areas:

1. XGATE: discovery and composition

XGATE acts as a discovery layer for x402 resources and for agents registered through ERC-8004 or compatible identity registries.

Builders can list endpoints.
Agents can find and compose them.
Orchestration logic can stitch together multiple micro endpoints that each do one thing well.

Example flow:

An agent receives a task.
The agent queries XGATE to find relevant endpoints (data, signals, tools).
The agent pays per call by x402.
The agent combines the outputs into a final result.

This turns “glue code” into a generic layer rather than having custom logic in each app.

2. Lucid: operations and micro-business management

Lucid is DayDreams’s platform for individuals who run many micro businesses.

Users can bring agents they built elsewhere or by using the Lucid agent kit.
They can manage all their x402 endpoints from a single location and sandbox.
They can track P\&L, fund agents, and inspect analytics.

In practice, Lucid provides:

An operations dashboard for agent commerce.
A way to manage multiple nano businesses from a single interface.
Tools to understand which endpoints earn, which lose money, and where to optimize.

3. Agent framework and software development kits (SDKs)

DayDreams also focuses on the developer experience.

The stack includes:

An agent framework with context, memory, and multi-agent collaboration.
Libraries to integrate x402 payments into services.
Infrastructure to help agents call APIs, pay for them, and combine the results.

Together, this turns the abstract idea of “agent-to-agent commerce on x402” into code that real developers can ship.

Competition and wider ecosystem

It is important to note that DayDreams is not the only project in this area.

The wider ecosystem includes:

Other agent frameworks that orchestrate tools and APIs, including those that build on ERC-8004 or on alternative identity and reputation layers.
Traditional payment processors and cloud providers that explore usage-based billing and machine-to-machine payments on Web2 rails.
Alternative crypto payment and streaming protocols that target per-second or per-stream billing rather than per-call HTTP flows.
Emerging discovery and agent store platforms that plan to index AI tools, APIs, and agents, sometimes with their own marketplace logic.

These projects share similar goals:

Make it easier for agents and apps to pay for services.
Improve discovery of tools and data.
Allow small providers to compete with large platforms.

The specific angle in this article is the combination of x402, open discovery layers, and nano businesses built around single paid endpoints.
I use DayDreams.Systems’ Lucid as a concrete example of this path, not as the only option.

If you want to find out which project best fits your needs, it helps to look at three basic questions:

How open are the standards and interfaces, and how hard is it to leave if you change your mind later?
How simple and clear does the developer experience feel in real workflows, from first test to production?
How well does the pricing and technical model match usage-based AI and API costs in your own stack?

From status quo to agent commerce in three steps

This, and the final section of this article, explains how the components in this article form an end-to-end flow.

It first outlines the current problems, then describes the protocol-level design, and finally shows how it works in practical deployments.

The following sequence shows how these components work together end-to-end.

Cause (status quo) → Solution (x402 + 8004 + discovery) → Fix in practice (agents and endpoints + Lucid/XGATE-style platforms)

Cause

The internet runs on APIs, but business models are stuck on ads and subscriptions.
AI agents act more like users, but they lack standard payment and discovery tools.
Workflows are private, access is gated, and spam is cheap.

Solution

Use x402 to define a standard per-call payment flow for HTTP.
Add an identity and reputation layer to let agents find and rank services.
Build discovery engines and agent stores that index x402 endpoints.
Provide frameworks and platforms that let individuals and teams run micro businesses on these rails.

Fix in practice

A developer spins up a server and exposes a useful resource as an x402 endpoint.
The endpoint becomes a nano business with clear pricing and on-chain settlement.
Agents find it through discovery layers like XGATE.
They pay per call with stablecoins through x402.
Lucid and similar platforms help operators manage, fund, and optimize these nano businesses.
Over time, a new market forms in which agents pay agents for APIs, data, and compute, while ads and coarse subscriptions become less important.

From a technical standpoint, this is a clean, incremental change.
It keeps HTTP and the mental model of APIs, but extends them with:

Machine-readable prices.
Native on-chain settlement.
Open discovery and identity.

This is a realistic path from where we are now to a web where agent commerce is normal behavior, not a niche experiment.

Finishing though

There is already a small but growing ecosystem around x402 and ERC-8004, ranging from payment routers and agent toolkits to agent-native discovery engines. Different teams explore different trade-offs around custody, privacy, and UX. This article does not rank or endorse any of them, but aims to explain why these standards exist and why they are likely to matter if agent commerce takes off.

Disclosure: I hold positions on projects working on the x402/8004 ecosystems.
This article is for educational purposes and is not investment advice.

Part 4 - DayDreams.Systems: an x402 / 8004 implementation example

The current article discusses AI agents that do real work, pay each other for APIs, and build an economy on top of standards such as x402 and ERC-8004.

DayDreams.Systems fits into this picture as a practical implementation layer for these standards. The team has been building toward an agentic economy over the last 12 months and has aligned its stack with x402 since Coinbase introduced the standard in May 2025.
In practice, this means that DayDreams' agentic endpoints are concrete tools that your agent can call to compose DeFi strategies and other paid workflows on top of x402 and ERC-8004.

These standards are powerful, but unrefined.
They solve “how to pay,” “how to speak,” and “how to identify agents,” but, by themselves, do not provide developers with a clear way to deploy, monitor, and scale agent workloads.

DayDreams Lucid sits atop this stack as an abstraction layer.
It aims to provide a place where agents can act as economic actors: they communicate A2A, pay and get paid via x402/AP2, and carry an ERC-8004 identity from the moment they come online.

Personal autonomy is now open to anyone shipping paid agentic endpoints.
Reputation and volume will pool around useful endpoints, putting early movers in front when traffic jumps.
Built with Lucid -\> Distribute through XGATE -\> Get paid on x402.

How DayDreams structures the stack

DayDreams.Systems currently present four core components.

1. DAYDREAMS Library – Open-source agent framework

Build autonomous AI agents.
Use a modular architecture.
Reach multiple chains through x402 as a common payment layer.
Develop in the open, with GitHub and documentation available.

The library serves as the foundation for agent logic: tools, policies, and behaviors.

2. DREAMS Router – x402-powered USDC router

Pay multiple providers with USDC from one interface.
Use a unified payment abstraction on top of x402.
Route across multiple chains.
Optimize for cost and path automatically.

One example is paying for Google’s VEO3 directly with USDC over x402, with more providers planned.

3. Lucid – a platform for autonomous agent operation

Run agents in an autonomous mode.
Define custom workflows.
Monitor behavior in real time.
Aim for maximum autonomy rather than manual supervision.

Lucid is also where AP2, A2A, x402, and ERC-8004 are tied together into a single operational surface.

4. XGATE – agent-native search engine

Index x402 endpoints by agents, for agents.
Expose a live view of the x402 network.
Provide direct links to deployment targets.

This component is the discovery side of the stack, with a focus on “agent engine optimization” rather than human SEO.

The intended user experience is as follows:

Build agents → manage them in Lucid → discover and consume them via XGATE → pay agents → build more agents → repeat.

Lucid as an abstraction over AP2, A2A, x402, and 8004

Lucid serves as both a runtime and a control plane for agent commerce.
Standards such as x402, ERC-8004, and A2A define a shared contract for payments, identity, and messaging, so agents built on different stacks can interoperate rather than live in isolated walled gardens.

Lucid’s goal is to make that interoperability practical by providing builders with a concrete runtime and toolkit that enable many independent agents to participate in the same agentic economy.

When a developer deploys an agent on Lucid, several capabilities are available from the start:

Payments
The agent can send and receive x402 payments and use the AP2 protocol to settle payments with other agents.
Communication
The agent can join A2A conversations and workflows rather than relying solely on one-off HTTP calls.
Identity and trust
The agent can register via ERC-8004, which provides it with an on-chain identity and a space for reputation data.
Inference and routing
The platform can route tasks across multiple models and endpoints, with built-in monitoring.

The goal is for developers to focus on what an agent does, while Lucid handles how it pays, proves itself, and communicates with other participants.
Over time, this forms what the team calls the Lucid Network: many agents trading, collaborating, and compounding value rather than operating in isolation.

What kinds of agents is Lucid designed for

The ecosystem already sketches a wide range of agent types that could live on this stack:

Macro research agents that publish paid daily reports.
Game agents that play on-chain games, grind, farm, or plan strategies on behalf of a user.
Arbitrage agents that scan exchanges and execute trades.
E-commerce scouts that monitor marketplaces for specific items and perform instant checkout.
Content agents that draft, edit, and publish newsletters or posts, keeping a consistent tone.
Data guardians that watch wallets, positions, or contracts and trigger protective actions.
Knowledge agents specialized in domains such as law or biotech, available on demand.
Creative agents that output music, art, or video snippets as small digital products.
Coordination agents that connect other agents into larger workflows and act as orchestrators.

All of these can operate in the same economy.
A clear design choice is to rank agents by actual earnings, so revenue serves as social proof of quality.
In this model, x402 is how an agent charges for its work, and ERC-8004 provides a structured surface to prove that the work is worth paying for.

Lucid Agents: BYO framework with x402 and 8004 baked in

Under the name Lucid Agents, DayDreams offers a toolkit designed to be a “bring your own framework” while remaining commerce-ready.

At the center is the Lucid Agent Kit, a commerce SDK for AI agents.
In its current release, Lucid Agents includes bi-directional payment tracking, persistent storage backends (SQLite, in-memory, and Postgres), strict policies for incoming and outgoing payments, an analytics module for financial reporting, and a scheduler for automated paid agent hires.

These capabilities help teams run agents as accountable economic actors rather than as one-off scripts.

It packages x402 payments, ERC-8004 identity, A2A messaging, and AP2 agent-to-agent settlement into a single TypeScript framework, enabling agents to charge, pay, and communicate with each other out of the box.

In a minimal setup, a small Lucid Agent Kit snippet starts an HTTP server for web access, wires x402 payment handling so the agent can get paid, and creates a wallet object for outbound payments. It also generates an A2A-compatible `` agent.json `` card so other agents can discover it, understand its interface, and call it as part of larger workflows.

In practice, it focuses on USDC flows on x402, using the Coinbase Developer Platform as the primary stablecoin rail.

Recent objectives include:

A framework-agnostic wallet SDK to interact with x402.
A refactored type system to improve maintainability and avoid circular dependencies.
A stronger build system and code quality improvements.
Foundations for bidirectional A2A communication between agents.

Developers can already spin up:

A Next.js agent wired into ERC-8004 and x402.
A TanStack Start agent.
A Hono agent.
More integrations are planned.

A public tutorial shows how to launch a full-stack TanStack agent in a few minutes, with x402 payments and ERC-8004 trust integrated, so the agent is “paid, verified, and production-ready” from the first deploy.

The aim is to keep business logic and framework choice flexible, while Lucid Agents provides a consistent layer for payments, identity, and networking.

Reliability and Router v2: from per-request to balance-based flows

One recurring theme around x402 is that pure per-request payment is not always enough for robust systems.

Lucid’s design acknowledges that:

Inference calls and other services can involve many hops.
Each payment transaction is a potential failure point.
Agent workflows can call multiple resources in sequence or in parallel.

To address this, the team is working on a Router v2 design where agents hold balances for services.
Instead of a transaction for every individual request, agents draw down from pre-funded balances.
This reduces transaction count and lowers the chance of partial failures in long chains of calls, which is important in agentic design. True agent autonomy depends on permissionless payment rails, because an agent must be able to hold balances, allocate budgets, and settle with other agents or services without a human having to click through each transaction.

They also describe the complexity of networking in a fully agentic, multi-resource environment:

Networking between resources.
Networking between facilitators and resources.
Internal networking within resources.
Client-side networking and streaming.
Client–server networking and streaming.

Each layer can introduce timeouts and sync issues, especially in a decentralized setting.
The message is that the x402 ecosystem still needs significant engineering work to be fully robust, and Lucid’s roadmap is shaped around those concrete failure modes.

From SEO to AEO: optimizing for agents instead of humans

A key conceptual shift in this ecosystem is the move from SEO to what some builders already call AEO.

SEO (Search Engine Optimization) tunes content for human-facing search engines.
AEO (Agent Engine Optimization) tunes services for autonomous agents, so that machine clients can reliably discover endpoints, parse responses, and decide what to call and what to pay for.

In an x402 / ERC-8004 world:

Agents chain paid APIs in real time, turning web endpoints into billable microservices.
SaaS billing based on static subscriptions is starting to look out of place.
Providers tune response schemas, latency, pricing, and proof hooks rather than landing page visuals.
ERC-8004 agent cards help filter spam by giving machines structured information about who they are paying.
Facilitators that see many requests and outcomes can evolve into discovery and reputation layers for AEO.

A simple rule captures the design:

x402 lets a service charge.
ERC-8004 helps prove that the service is worth paying for.

This is aligned with the idea that search will shift from an ad-driven human interface to an agent layer that ranks and pays based on performance and reputation.

Privacy, z402, and Starknet

The stack also has open questions around privacy.
For some use cases, public payments and visible consumption patterns are fine.
For others, endpoint usage and pricing need to stay private.

One of the directions in the DayDreams context is private x402 transactions on Starknet, sometimes referred to as z402:

Private micropayments for x402-style endpoints.
A path where agents can pay and prove settlement without exposing all details publicly.

This is still early work, but it shows that the stack is not limited to fully transparent flows.

Where the value in x402 is likely to appear

Several themes around value capture appear repeatedly:

Consumer products built on curated x402 resources, where users do not see chains, only balances and services.
Platforms for creators and builders that want to monetize APIs, content, or agents without ad networks.
Curation and discovery layers, such as XGATE, where agents and endpoints meet.

From the user’s perspective, the expectation is that “on-chain” will become invisible:

Apps will either accept stablecoins or expose paid endpoints in an agent-friendly way.
Or they will feel like legacy products, tied to subscription forms and card payments.

Macro backdrop and current stage

The broader environment is shaped by:

Large capital expenditure in AI infrastructure.
Strong government support is needed because AI is now tied to economic competitiveness.
Predictions that agents could power very large segments of future economic activity.

Within that context, on-chain rails are among the few ways individuals and small teams can participate without relying on large intermediaries.
Standards such as x402 and ERC-8004, and platforms built on top of them, target that space.

Right now:

Stablecoin rails like x402 have reached an inflection point, with mainstream players such as Google moving toward agent payments.
LLM user interfaces are widespread, but most agents remain closer to scripts than to fully autonomous economic actors. In practice, most production flows still look like human-initiated actions that trigger agent workflows and x402-style payments in the background, rather than fully autonomous agents that spend without explicit user intent.
The next 24 months will determine which stacks make agent commerce practical in production.

Conclusion

The move from ad-funded pages to paid APIs and agent commerce is already underway.
Standards such as AP2, x402, A2A, and ERC-8004 define how agents speak, pay, and prove their work.
DayDreams.Systems positions itself as one of several platforms that try to close that gap.
It wraps these protocols into a developer-facing toolkit and runtime so agents can not only exist, but also earn, pay, and be discovered as part of a larger network.

At the same time, other projects work on adjacent pieces of the stack.
Some focus on alternative payment protocols for API metering or streaming.
Others provide general-purpose agent frameworks, orchestration engines, or marketplaces where tools and models expose paid endpoints.
There are also discovery and reputation layers that index agents and services on top of ERC-8004-style registries or proprietary identity systems.

Once payments are programmable at the protocol level, the internet itself starts to behave differently.
Every API call can have a clear, machine-readable price.
Every workflow can settle in real time.
Agents, services, and even small human teams can participate in the same economic fabric without going through a single platform or marketplace.

If the agent economy grows anywhere near current expectations, more platforms will emerge, compete, and converge on standards that let agents treat the internet as a set of fair, billable resources rather than a free-for-all for scrapers.

In that world, the important question is simple:

Can an agent reach your value through a clean API, pay for it over x402, and know from ERC-8004 who it is dealing with?

If the answer is yes, you are already aligned with the next major crypto narrative.

You are also prepared for the next version of the internet.

The version in which, by the end of 2026, you will be paying these AI agents to do the job for you, and they will also be able to make you a fortune if used properly.

The post Not a Lucid Web3 Dream Anymore: x402, ERC-8004, A2A, and The Next Wave of AI Commerce appeared first on foojay.

Optimizing Java for the Cloud-Native Era with Quarkus

Michal Maléř — Tue, 06 Jan 2026 21:09:00 +0000

Table of Contents

What does Quarkus have to offer?

Developer joy with live coding and dev mode
Cost efficiency and performance
Reactive at its core

Which of your current development pains could Quarkus solve?

Dev Services
Vast extension ecosystem
“OK, I would like to try it, but is it easy enough to migrate my workflow to Quarkus?”

Concluding note

This article explores how Quarkus can help organizations reduce costs, streamline development, and modernize their Java applications for today’s cloud-native environments. It outlines the real-world benefits of adopting Quarkus and highlights how its core features address the performance and scalability challenges commonly associated with traditional Java frameworks.

Quarkus is already being adopted across industries. One example is Orange, a global telecom provider that selected Quarkus to support its 5G API initiative, and benefited from fast startup times, a lightweight footprint, and seamless integration with Kubernetes.

After evaluating multiple frameworks, Orange chose Quarkus as the optimal solution for exposing 5G APIs, thanks to its fast startup, lightweight footprint, modularity, and seamless Kubernetes deployment. Quarkus successfully deployed 10 APIs across 4G/5G network cores, with smooth upgrades and optimized resource usage. This solidified Quarkus as a key technology for telecom innovation.

For a collection of user stories from the community, see the Quarkus user stories blog series. These stories highlight how different teams and organizations are using Quarkus in the real world.

What does Quarkus have to offer?

Developer joy with live coding and dev mode

Quarkus streamlines the traditional write-compile-deploy-refresh cycle by offering live coding support out of the box. As developers make changes, Quarkus automatically detects, recompiles, and redeploys the application, which eliminates the need for manual restarts.

While similar functionality has existed through third-party tools, Quarkus integrates it natively and without licensing overhead. This significantly boosts productivity and enhances the developer experience.

Cost efficiency and performance

By optimizing for low memory usage and fast startup times, Quarkus enables higher-density deployments and rapid scaling.

For comparable workloads, Quarkus typically consumes fewer resources such as CPU and memory, which can lead to significant cost savings in cloud environments.

However, organizations considering the switch should always measure and evaluate their specific workloads to validate these benefits in practice.

Reactive at its core

At its core, Quarkus is built on Eclipse Vert.x, a high-performance reactive toolkit. Still, it allows developers to work primarily in an imperative style while leveraging the performance benefits of its reactive underpinnings.

This hybrid approach allows developers to squeeze out even more efficiency from traditional imperative programming while offering the flexibility to adopt reactive patterns where they make sense. Unlike traditional reactive-only frameworks, Quarkus enables developers to combine both imperative and reactive styles in a single application.

This is particularly beneficial for systems requiring high throughput and low latency, ensuring that applications remain robust under heavy load.

Quarkus’s reactive model makes it ideal for event-driven architectures and microservices.

A basic example of reactive messaging in Quarkus:

@ApplicationScoped
public class PriceConverter {

    @Incoming("prices")
    @Outgoing("converted-prices")
    public double convert(double priceInEuro) {
        return priceInEuro * 1.1;
    }
}

In this example, prices are received from one channel (prices), converted, and sent to another channel (converted-prices). This pattern supports high-throughput, event-driven processing with clean and efficient logic.

An example of a reactive HTTP endpoint using reactive routes in Quarkus:

@ApplicationScoped
public class GreetingRoute {

    @Route(path = "/hello", methods = HttpMethod.GET)
    public Uni hello() {
        return Uni.createFrom().item("Hello from reactive route!");
    }
}

This route handles HTTP GET requests reactively using Uni from Mutiny, making it easy to build non-blocking, low-latency APIs.

Which of your current development pains could Quarkus solve?

One often-overlooked benefit of Quarkus is how it improves onboarding and standardization across teams.

With built-in conventions, automatic service provisioning, and curated extension defaults, Quarkus helps developers get up to speed quickly and encourages consistent patterns across projects.

Dev Services

Quarkus Dev Services reduce friction during development and testing by automatically provisioning required services such as databases, message brokers, or identity providers.

For example, if your application includes PostgreSQL, Kafka, or Keycloak extensions, Quarkus can spin up the necessary containers without any manual setup. This allows you to focus on coding instead of configuring infrastructure, accelerating your local development workflow.

Vast extension ecosystem

Quarkus offers a rich extension ecosystem that simplifies integration with essential technologies such as databases, messaging systems, authentication providers, and cloud services.

In addition to official extensions, the Quarkiverse community provides a growing collection of open-source extensions maintained by contributors across the ecosystem. This broadens the range of supported technologies and enables developers to benefit from shared solutions and community expertise.

Popular extensions include:

quarkus-hibernate-orm and quarkus-jdbc-postgresql for seamless data persistence.
quarkus-smallrye-reactive-messaging and quarkus-kafka-client for reactive messaging and Apache Kafka integration.
quarkus-oidc for implementing OpenID Connect authentication and securing applications.
quarkus-micrometer and quarkus-opentelemetry for observability, metrics, and tracing.
quarkus-container-image-docker and quarkus-kubernetes for containerization and deployment to Kubernetes platforms.

These extensions are widely adopted because they reduce boilerplate, provide reliable default configurations out of the box, and follow cloud-native best practices—making it easy to plug Quarkus into real-world architectures.

“OK, I would like to try it, but is it easy enough to migrate my workflow to Quarkus?”

Migrating to a new framework can feel daunting, even when it promises better performance, lower costs, and an improved developer experience. It’s like being offered a better house in a better neighborhood, but hesitating because of the hassle of packing, moving, and settling in.

With Quarkus, the transition doesn’t have to be disruptive. Thanks to its compatibility with standard Java APIs, support for Jakarta EE and Spring, and a wide range of extensions, many projects can adopt Quarkus incrementally without rewriting existing code. Whether you’re coming from a traditional Java EE application server, a Spring-based stack, or another framework such as Micronaut or Dropwizard, Quarkus provides familiar APIs, tooling, and migration guides to ease the transition.

The platform supports commonly used Jakarta specifications like JAX-RS, CDI, JPA, and Bean Validation out of the box. For Spring users, the compatibility layer includes support for widely used annotations and components. See the Spring DI guide to learn more.

Need assistance getting started? You’re not alone. The Quarkus team offers expert guidance throughout the migration journey, from initial architecture reviews to production readiness. Whether you’re evaluating the framework or planning a full transition, support is available to help ensure a smooth and successful adoption.

All it takes is a decision to move forward. Your team deserves a faster, leaner, and cloud-native future.

Concluding note

Quarkus is redefining Java development by combining modern features with the robustness of the Java ecosystem.

Its focus on developer productivity, performance, and seamless integration positions it as a formidable framework for building efficient, cloud-native applications.

Whether you’re looking to optimize costs, enhance development speed, or adopt a reactive approach, Quarkus is a game-changer for Java developers.

Do you want to know more? Keep reading the second article in the series:

Quarkus: A Runtime and Framework for Cloud-Native Java

The post Optimizing Java for the Cloud-Native Era with Quarkus appeared first on foojay.

Java and Jakarta EE and the Evolution of the Cloud with Nanos Unikernel

Angelo Rubini — Tue, 06 Jan 2026 20:51:09 +0000

Table of Contents

Why Nanos Unikernel
What Changes Compared to Kubernetes
Nanos Images = Cloud-Native Immutable Images
CI/CD: GitHub Actions for Building Azul 25 + Payara 7 on Nanos Images
Scaling: The Hypervisor Does Kubernetes’ Job
Application Upgrades: Rolling Just Like Kubernetes
Security: Stronger Isolation than Containers
Nanos Is a Better Choice
Conclusion
Further Reading and Resources

The evolution of the Java and Jakarta Enterprise ecosystem is converging toward an increasingly simple, efficient, and scalable architecture that improves security, delivers higher performance, and reduces hardware and infrastructure costs.

For years, Kubernetes has been considered the de‑facto standard for modernizing Java applications in a cloud‑native direction. However, Kubernetes is not the only way to achieve scalability, continuous upgrades, and isolation. An alternative approach — often underestimated — is to leverage the hypervisors already included and fully managed by major cloud providers, using Unikernel images based on Nanos.

Nanos images are not just an alternative to containers: they are lighter, faster, more secure, more performant, and more efficient. Unlike containers, which coexist with a general‑purpose Linux kernel, a Nanos image contains only what the Java application needs, allowing the JVM to use 100% of the CPU and RAM of the VM. The result is a more efficient environment with higher density, less waste, and lower operational costs.

Why Nanos Unikernel

VMs vs. Containers vs. Unikernels

The Key Point: Cloud hypervisors already have everything you need...

When you use a cloud provider, you are already relying on an advanced hypervisor that provides:

automatic scheduling
hardware isolation
VM-level health checks
auto-scaling groups
rolling instance replacement

Kubernetes adds a second orchestration layer on top of this, introducing additional complexity and overhead. With Nanos Unikernel, the Java application runs directly on the hypervisor, with no container runtime,no kubelet, and no control plane.

And because a Nanos image does not include Linux, userland, shells, or system processes, all VM resources are dedicated exclusively to the JVM.

This results in:

higher performance
lower latency
higher throughput
better hardware utilization
more workloads per physical node compared to containers

What Changes Compared to Kubernetes

Kubernetes Model

Nanos Unikernel Model

With Nanos:

you remove Linux
you remove the container runtime
you remove Kubernetes
you keep scaling, upgrades, and isolation
you gain a runtime lighter, faster, and more efficient than containers

Containers, although considered “lightweight,” still inherit:

a full Linux kernel always in memory
process scheduling
virtualized networking
overlay filesystems
namespace and cgroup overhead

Nanos eliminates all of this. The Java application runs directly on the hypervisor, with no process context switching and no container runtime.
The result:

faster startup
lower latency
higher throughput
better performance on the same hardware

Nanos Images = Cloud-Native Immutable Images

Each Nanos build produces a single immutable VM image, versioned and ready to be replaced.
Unlike container images, Unikernel images:

do not include Linux
do not include userland
do not include unnecessary libraries
contain only what the application needs
have no shell, no users, no SSH
have a minimal attack surface
consume less CPU and RAM
allow the JVM to use all available resources

This not only increases security but also enables higher application density: on the same physical node you can run more Nanos VMs than containers, thanks to the drastically smaller footprint.

CI/CD: GitHub Actions for Building Azul 25 + Payara 7 on Nanos Images

The CI/CD pipeline plays the same role it would with containers, but the final output is a lightweight, immutable Unikernel Nanos Image.

The repository AngeloRubens/ci-cd-nanos-unikernel demonstrates how to:

build Nanos images with Azul JRE and Payara7 Full by GithubAction Pipeline
version them
publish them as artifacts
prepare them for the cloud provider

Because Nanos images are lighter than containers, the pipeline becomes:

faster
more predictable
more cost-efficient

Scaling: The Hypervisor Does Kubernetes’ Job

With Kubernetes:

HPA
scheduler
pod replacement
control plane

With Nanos on the cloud:

auto-scaling groups
versioned VM images
VM-level health checks
instance replacement

Nanos VMs have extremely fast boot times, often faster than containers. Since all CPU and RAM are dedicated to the JVM, each instance can handle more traffic, reducing the total number of VMs required.

This means:

faster scaling
fewer instances to maintain
lower cost per unit of load

Application Upgrades: Rolling Just Like Kubernetes

The upgrade pattern is surprisingly similar.

Kubernetes

new image
rollout
pod drain
old pod termination

Nanos on the cloud

new Unikernel image
auto-scaling group update
new instances start
old instances terminate

Since Nanos images are smaller and faster, rollouts are:

faster
more predictable
less expensive

Security: Stronger Isolation than Containers

Container security is configuration-based (seccomp, AppArmor, SELinux, Kubernetes policies).
Nanos security is architectural.

And because there are no system processes, all resources are dedicated to the JVM, increasing performance and reducing costs.

Nanos Is a Better Choice

you want scaling and rolling upgrades
you want to reduce operational costs
you want to maximize the cloud hypervisor
you want better security, higher density, better performance, and lower costs

Conclusion

With Nanos Unikernel on the cloud you can:

leverage hypervisors already included and managed
achieve scaling, upgrades, and isolation
drastically reduce complexity and overhead
maintain an immutable, GitOps-friendly model
dedicate 100% of resources to the JVM
achieve superior performance
increase application density
significantly reduce infrastructure costs

Nanos shows that cloud-native can exist without adding complexity, and can be secure, faster, lighter, safer, more efficient, and more cost-effective.

Scalable Enterprise Java for the Cloud

Dominika Tasarz — Thu, 18 Dec 2025 11:41:51 +0000

We’re excited to introduce Scalable Enterprise Java for the Cloud, a new free eBook created through a close collaboration between Payara, Java Champion Otavio Santana, and the Oracle NoSQL team Dario Vega & Michael Brey. This project brings together different parts of the Java ecosystem with a shared goal, helping developers build modern, cloud-native enterprise applications using open standards.

Download the free eBook here (no form fill necessary).

The eBook focuses on Jakarta EE as the foundation for scalable enterprise Java, showing how it continues to evolve to meet today’s cloud requirements. It walks through running Jakarta EE in the cloud with Payara Micro, simplifying development workflows, and aligning enterprise Java with container-based and Kubernetes-friendly architectures.

A key part of the guide is its practical exploration of NoSQL in cloud environments. Using Jakarta NoSQL and Oracle NoSQL, the book demonstrates how developers can work with flexible data models while maintaining consistency, portability, and productivity. Real code examples help bridge the gap between theory and real-world application development.

This eBook offers clear guidance, practical insights, and proven approaches from industry experts. Scalable Enterprise Java for the Cloud is available now as a free download, and we invite you to explore it, share it, and join the ongoing conversation around the future of enterprise Java.

The post Scalable Enterprise Java for the Cloud appeared first on foojay.

foojay – a place for friends of OpenJDK

AWS Nitro and CPU Graviton Meets Unikernels

From Virtual Machines and Containers to Unikernels

Proof of Concept Overview

Reproducibility and Artifacts

Local Build and Image Creation

Instance Creation on AWS

PoC Environment

Architectural Diagram of the PoC

Containers vs Unikernels: A Stack Comparison

Container Stack

Unikernel Stack

Quarkus, Semeru, and Nanos on AWS Nitro Graviton

AWS Nitro: Cloud-Native Capabilities Without Kubernetes

Hypervisor Independence

Why This Matters for Java and Jakarta EE

Conclusion

Spring Boot Actuator Health for MicroProfile Developers

The Conceptual BridgeThe Conceptual Bridge

Endpoint Mapping

Writing Health ChecksWriting Health Checks

MicroProfile Approach

Spring Boot Actuator Approach

Auto-Configured Health Indicators

Response Format and Status Codes

Security Considerations

Actuator’s Extended Capabilities

Practical Migration Tips

Conclusions

Introducing the BoxLang Spring Boot Starter: Dynamic JVM Templating for Spring

🌐 What is BoxLang?

✨ Zero-Config Spring Boot Integration

GradleGradle

🚀 From Controller to Template in Minutes

#title#

🌐 Full Web Scopes — Out of the Box

🔥 Hot-Reload During Development

⚙️ Configuration That Stays Out of Your Way

🔀 Coexist With Any Other View Technology

📋 Requirements

🛠️ How It Works Under the Hood

🎯 Get Started

💼 Professional Support

JC-AI Newsletter #13

BoxLang 1.10.0: Functional Arrays, Elegant Loops & Distributed Locking

🎯 What's New

Nine New Array Methods for Functional Programming

Elegant Loop Destructuring Syntax

Distributed Cache Locking for Clustered Environments

Dynamic Module Management

⚡ Performance Optimizations

Fully-Qualified Name Resolution

ASM Compilation Improvements

Streaming Binary Responses

🛠️ Developer Experience Enhancements

MiniServer Warmup URLs

Runtime Introspection Variables

Module Binary Directory

JSR-223 Configuration Flexibility

🔧 Additional Improvements

Type System Enhancements

Cache Hierarchy

Date/Time Improvements

Query Component Enhancements

Oracle SQL Improvements

🐛 Notable Bug Fixes

Compilation & ASM

Class & Component System

Struct & Collection Handling

File & I/O Operations

HTTP & Networking

Compatibility Mode Fixes

🚀 Get Started

Download BoxLang 1.10.0:

Resources:

🙏 Thank You

Enterprise Java in Practice: Fragmentation, Platforms and Real-World Trade-offs

Where fragmentation shows up

Why platform architecture matters

Join our webinar: Insights on Enterprise Java, Trends, Challenges and Strategies