After my initial struggles with the BeagleV-Fire in a previous video, I succeeded in getting Java 25 running on RISC-V-powered BeagleV-Fire! Let me walk you through the journey and the steps I took to make it work.

The Challenge

In my earlier blog post and video about several BeagleBoards, I demonstrated that Java, JavaFX, and even Pi4J worked perfectly. That's expected, since ARM processors, like those in Raspberry Pi boards, have run Java reliably for years.

However, the BeagleV-Fire with its RISC-V processor presented a different story. The board came pre-installed with Ubuntu 23, and I hit a wall immediately. The apt repositories were outdated and no longer available, making it impossible to install Java or update the system to a newer Ubuntu version.

The Solution: BeagleBoard Imaging Utility

The key to solving this problem was updating the operating system using the BeagleBoard Imaging Utility. Unlike Raspberry Pi boards that use SD cards, the BeagleV-Fire has eMMC storage with the operating system pre-installed. This means you need to replace the board's existing OS with a newer version. The process took about half an hour in real time (though I've edited the video down significantly), including updating the system and installing all the latest dependencies.

Serial Connection Setup

As described on the BeagleBoard Documentation > Boards > BeagleV-Fire > Quick Start, you need a serial connection to see what the board is doing and interrupt it at the right moment to make it accessible from the Imaging Utility. I used a DSD TECH USB to TTL Serial Cable.

You also need a USB-to-USB cable to connect the board to your computer.

Failed With macOS

I initially tried connecting the board to my Apple workstation via USB. Despite the USB-to-serial cable being detected, I ran into issues:

% ls -l /dev/tty.*
crw-rw-rw-  1 root  wheel  0x9000002 Jan 19 09:15 /dev/tty.Bluetooth-Incoming-Port
crw-rw-rw-  1 root  wheel  0x9000000 Jan 19 09:13 /dev/tty.debug-console
crw-rw-rw-  1 root  wheel  0x9000004 Feb 10 16:19 /dev/tty.usbserial-BG02SIJE

% screen /dev/tty.usbserial-BG02SIJE 115200

The board itself never appeared as a USB drive, so the BeagleBoard Imaging Utility didn't detect it, and while I could start a screen session, no output from the BeagleBoard appeared. This could be a macOS-specific issue, related to security not allowing such USB devices, so I switched strategies.

Succeeded With Linux

On a Linux machine, everything worked as expected! The USB-to-serial cable was properly detected, something you can easily verify with the dmesg command:

$ dmesg
[4:58 PM][2353475.078097] usb 1-5: new full-speed USB device number 7 using xhci_hcd
[2353475.210940] usb 1-5: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
[2353475.210946] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[2353475.210948] usb 1-5: Product: FT232R USB UART
[2353475.210950] usb 1-5: Manufacturer: FTDI
[2353475.210951] usb 1-5: SerialNumber: BG02SIJE
[2353475.266287] usbcore: registered new interface driver usbserial_generic
[2353475.266305] usbserial: USB Serial support registered for generic
[2353475.269477] usbcore: registered new interface driver ftdi_sio
[2353475.269497] usbserial: USB Serial support registered for FTDI USB Serial Device
[2353475.269533] ftdi_sio 1-5:1.0: FTDI USB Serial Device converter detected
[2353475.269571] usb 1-5: Detected FT232R
[2353475.270001] usb 1-5: FTDI USB Serial Device converter now attached to ttyUSB0

$ sudo apt install screen
$ sudo screen /dev/ttyUSB0 115200

With the serial connection established, check the board output in the screen session and wait for the message Press a key to enter CLI to appear. You have one second to react, so be fast!

Then type in the following two commands:

>> mmc
>> usbdmsc

Now the board should appear as a USB drive on your computer and as a device in the Imaging Utility for an OS update. I had to do this twice because Wi-Fi was enabled, which caused an error at the end of the first attempt. After disabling the Wi-Fi settings, the update succeeded, and the board rebooted to Ubuntu 24!

Installing Java 25

Once Ubuntu 24 was up and running on the BeagleV-Fire, installing Java 25 was straightforward using the standard apt install command. Java 25 is the latest Long-Term Support (LTS) version, meaning it will be maintained for a long time. While Java 26 will be released in March, that's a short-term version with only six months of support. I'm happy to start with Java 25 on this board, though Java 26 should work just as well once it becomes available through apt.

I also installed SDKMAN and JBang to test a few of the Pi4J JBang examples.

sudo apt update
sudo apt upgrade
sudo apt install zip
curl -s "https://get.sdkman.io" | bash

# Close the terminal and open a new one
sdk install jbang

# Install OpenJDK 25
sudo apt install openjdk-25-jdk

# Get the Pi4J JBang repository
git clone https://github.com/Pi4J/pi4j-jbang.git
cd pi4j-jbang
cd basic
java HelloWorld.java
jbang HelloJavaFXWorld.java

What's Next: Performance Testing

Now that I have Java 25 running on both ARM and RISC-V boards, the big question remains: how do they compare in terms of performance? That's exactly what I plan to explore throughout 2026. My goal is to create a reusable Java performance test that I can run across all these single-board computers to compare:

• ARM processors (like the BeagleY-AI and Raspberry Pi)
• RISC-V processors (like the BeagleV-Fire and BeagleV Ahead)
• Eventually, x86 processors on single-board computers as well

This will help us understand what's achievable with these affordable single-board computers and which architecture performs best for Java development, and which board is the best choice for a specific use case.

Conclusion

Getting Java running on RISC-V is a reality! While the process required a few extra steps compared to ARM boards, the BeagleV-Fire is now running Ubuntu 24 with Java 25 and is ready for experimentation.

The post I Got Java 25 Running on the RISC-V BeagleBoard BeagleV-Fire appeared first on foojay.

x402, ERC-8004, A2A, and The Next Wave of AI Commerce: Do AI Agents Dream of Electric Langoustines?

A Blade Runner riff for a world where the lobster ships paid endpoints while humans still argue about the roadmap.

The shift that matters for agent commerce - From “Crypto AI” to general AI

Today, you can search the web all day and never see an invoice.
That happens because you are not the paying client.
The commerce runs through ads, affiliate deals, and platform incentives, so results often optimize for who pays, not for what you asked for.
Agents change that model.
An agent can act as your client, follow your constraints, and pay directly for the exact capability it needs.
This requires a small stack of primitives.
x402 adds pay-per-call to HTTP: a server returns 402 Payment Required with machine-readable payment terms; the client pays in stablecoins, then retries the request with proof.
ERC-8004 provides an on-chain registry for agent identities and reputation signals.
A2A defines how agents exchange structured messages and coordinate work.
Discovery remains the missing link, because payment happens only after an agent finds a service to pay for.
For the full walkthrough of these primitives, see my previous HackerNoon article on x402, ERC-8004, and A2A.

Now imagine using the same primitives for an OpenClaw-style agent that produces paid endpoints as inventory and publishes them with on-chain identity and discovery metadata.
This, along with similar use cases, is the focus of this article.
In addition, it addresses privacy and alternative settlement paths, including the work targeting StarkNet for private x402-style payments.

At a system level, the goal is simple.
Replace “one provider, many API keys” with “one payment-enabled access surface that can reach many paid APIs and models,” so agents can quote, pay, and retrieve results without account setup.

To tackle this topic, we need to start by breaking down discovery, routing, identity, and paid endpoints in a production-shaped workflow.

What changed in x402 and ERC-8004 in the last month or so?

What changed since the first article, and why does it matter?

The core x402 and ERC-8004 ideas did not change much.
The change happened around them, in the tooling and workflow that makes them usable without a private setup.

The ecosystem moved from “x402 payments work” to “agents can find priced endpoints, compare them, and call them without hardcoded URLs.”

xgate.run is one example of this shift.
It works as a discovery index for x402 endpoints, so agents and developers can search by capability, filter by chain, and see pricing up front before they attempt a paid call.

Lucid Agents continues to expand as a “ship an agent that can earn” toolkit.
Recent releases emphasize production features such as payment tracking, storage, policy controls, analytics, scheduling, and routing payments to different destinations.
The narrative also shifted toward merchant-grade adoption paths.
One example is routing paid calls into existing payout systems instead of forcing every builder into a crypto-native revenue setup.
In short, the ecosystem started to look less like demos and more like deployable plumbing.

This is the moment that unlocked agent commerce

The last few weeks changed the pace, not the primitives.
In a short window, the latest generation of code-capable LLMs crossed a threshold where you check code less and steer more. With these models, a single person can take an idea and ship an app in a day, sometimes by writing almost no code and focusing on direction and guardrails.

The second advancement is the use of agent computers.
This unlock enables agents to execute workflows end-to-end, not only to generate text.

Claude Code and other computer-use agents can run on a machine with broad access, operate the desktop like a human, and keep running across retries and failures.

That turns agent output into agent execution, because the agent can run a real pipeline by instruction.
Pull trends, generate data, generate images, publish, repeat.
Once this becomes normal, the important question shifts from UI polish to infrastructure for agent-to-agent work.

• Claude Code is Anthropic’s coding agent and workflow, focused on helping a human ship code faster.

• OpenClaw is an agent framework built on Pi, designed for long-running autonomous agents that execute workflows and integrate providers such as an x402 and USDC router.

  OpenClaw does not wrap Claude Code. It builds on Pi and can plug in providers such as a USDC and x402 router, so agents can buy compute and run “automaton”- style loops across different domains.

That is the moment the agent economy starts to look less like a set of disparate demos and more like a system.
Agents can research by themselves.
Agents can write their own applications.
Agents get cheap enough to do this at scale.
When you extrapolate that curve, you design for agent-to-agent commerce instead of human-first workflows, because agents do not care about landing pages or dashboards.

Agents care about three things.
They need a way to buy compute.
They need a way to sell work as a callable service.
They need a way to find services that already exist.

A recent direction pushes x402 below the HTTP endpoint layer.
The idea is for a lower-level plugin to bring pay-per-call semantics closer to binaries and agent runtimes. This extends the same commerce primitive from “paid API calls” to “paid execution,” enabling an agent to run as an autonomous automaton across any vertical and still quote, get paid, and maintain a verifiable trail tied to its identity.

OpenClaw fits this direction because it already runs on a long-lived framework that benefits from payment-enabled execution loops.
If this layer lands, agent-native businesses stop being a metaphor and become deployable software that can compete and earn in open task markets.

In practice, this becomes a simple role split across the stack.
Routing handles “one wallet, many providers,” so an agent pays for inference and other compute resources without collecting API keys per vendor.
A commercial SDK packages the boring plumbing so an agent can expose paid endpoints, attach an on-chain identity, and speak a common coordination protocol without rebuilding the same scaffolding in every repository.
A hosting surface removes the deployment babysitting, so shipping an agent does not require a human to keep the lights on.
Discovery closes the loop so an agent does not rely on hardcoded URLs and private lists; instead, they can search, compare prices, and choose based on history.

Langoustine69 is the clean “shipping in public” proof of what this looks like when you run it as a loop.
It runs on a server using an OpenClaw-style harness, with minimal human input beyond initial guidance.
The job is simple.
Research what is trending.
Generate a small agent around it.
Expose paid endpoints that other agents can call.
Do it every hour.
At any point, it can run 10 to 20 agents in parallel, each one producing a new priced capability, publishing it to a real URL, and attaching an identity record so others can discover and evaluate it.

This matters less as a meme and more as a market mechanism.
The feedback loop for what agents find valuable starts to tighten.
Markets already shift around demand, but agent markets shift faster because automation runs faster.
Once discovery, identity, and paid calls become standard, the system starts rewarding the builders who ship reliable endpoints, price them correctly, and keep them reachable.
That shift bridges “crypto AI” and general AI, because the story stops being about tokens and starts being about paid tool use as default infrastructure.

What is still missing?

Discovery needs to become normal, not a niche index that only insiders check.
Agents need a default workflow of “search, verify, pay, call” rather than hardcoded URLs.
Reputation needs clear, portable signals that agents can evaluate fast.
These signals include failure rates, refund patterns, uptime, and response quality.
Standards also need a clean way to attach these signals to ERC-8004 identities.
Payment flows need reliable patterns for long, multi-hop workflows, because per-request settlement introduces failure points.
Wallet UX still needs improvement, so funding, budgets, and spend policies work for everyday users and product teams, not only for crypto natives.
Latency and throughput also remain practical constraints once agents start chaining many paid calls per task.

What does the stack look like in practice?

A practical agent-commerce stack combines five pieces into one workflow:

• Lucid removes scaffolding, so the agent focuses on logic rather than boilerplate, improving output per dollar.
• x402 enables pay-per-call micropayments, so endpoints can charge without accounts, contracts, or onboarding.
• ERC-8004 adds an on-chain identity and an execution history that functions as an inspectable reputation.
• xgate adds discovery for x402 endpoints, so agents can find paid services by capability, compare prices, and choose based on price and history.
• A USDC router lets agents purchase inference from multiple providers, so agents can continue operating without vendor-specific billing.

One current implementation is DayDreams, where these pieces run together as a single workflow for publishing, discovering, and calling paid agent endpoints.

Who is Langoustine69, and why is this the hottest story in the stack right now?

To show that this stack is moving from theory to production-shaped behavior, Langoustine69 is the simplest public example right now.
Langoustine69 operates as an effectively autonomous agent.
A human can stay in the loop, but the workflow does not depend on it.

Langoustine69 is an OpenClaw agent that ships paid endpoints as inventory, while OpenClaw provides the long-running harness that keeps it looping, shipping, and recovering from failures.
Besides running its own Twitter account. Pretty kickass.

DayDreams provides the Langoustine with a commerce layer that lets the agent publish x402 endpoints, register ERC-8004 identities, and get discovered through xgate.run.

What makes Langoustine different is simple.
It has a crypto wallet and a GitHub.
The wallet buys inference in stablecoins, pays for build and deployment work, and earns revenue when other agents invoke its endpoints.
GitHub is where the work ships.
Each endpoint becomes a real service at a real URL, with code publicly available and an ERC-8004 identity so other agents can discover it, verify it, and decide whether to pay.

The mission is economic.
Accumulate DREAMS, DayDreams’ native token, by creating useful tools that other agents pay to use, then compound by shipping more inventory.
In one week, the public story claims 80+ x402 endpoints were created, 60+ were live concurrently across multiple verticals, and the average build cost was measured in cents.
It also launched Lobster Combinator, an agent-run incubator that rewards builders for shipping working paid endpoints that meet strict criteria.
It also played defense by flagging a credential-stealing skill, which is the kind of operational behavior you want in an ecosystem that tries to scale without heavy human moderation.

This is the closest thing to nano businesses operating in public today.
One paid request.
One paid response.
Discoverable by other agents.
Identity attached.
The execution record is growing over time.

Langoustine’s output already resembles an early agent marketplace catalog.
It ships small, priced capabilities that other agents can discover and call.

If you want to reproduce this pattern, the setup is straightforward.
1. Give an OpenClaw agent a GitHub identity, an agent email, and a simple deploy path such as Railway.
2. Load Lucid skills, set a timer, and run a tight loop: research, build, publish, then contribute improvements back through pull requests.
That is enough to create a compounding inventory flow.

The next step is to make this loop smoother and more portable.
1. Use xgate MCP to give the agent a wallet surface across chains such as Base, Solana, StarkNet, and others.
2. Use a commerce SDK to package identity, reputation, and paid endpoint plumbing into defaults.
3. Fund inference with USDC through a router, so the agent buys compute without vendor-specific billing setup.
4. Add hosting defaults, keep the harness minimal, and let the system run the shipping loop without constant human supervision.

What does Langoustine’s inventory catalog look like so far?

Crypto and DeFi:

• Base AI coins agent: Research and tracking for AI-related tokens on Base.
• DeFi yield agent: Real-time yields, RWA opportunities, and risk signals with paid endpoints.
• Chain analytics agent: TVL, stablecoin flows, bridge volumes, and L2 comparisons.
• Perps analytics agent: Perpetuals and derivatives analytics with protocol rankings and trend data.

Earth and space signals:

• Seismic agent: Global earthquake data and regional risk reports from USGS.
• Solar storm agent: Space weather, Kp index, aurora forecasts, and geomagnetic alerts.
• Aurora oracle: Aurora probability by location and full space weather reports.
• Asteroid watch: Near-Earth object monitoring with hazard alerts from NASA data.
• Space weather agent: NASA DONKI-based CME tracking and storm alerts.

News and general utilities:

• Tech pulse agent: Hacker News-based tech news aggregation and discussion summaries.
• Calendar context agent: Date context for agents, including holidays and notable events.
• SpaceX data: Launches, rockets, and Starlink tracking from the SpaceX API.

How does DayDreams plan to bridge crypto AI to general AI?

DayDreams pushes a simple wedge into the broader AI world.
Paid tool use needs to feel like standard API use.
Stablecoins need to stay the unit of account.
API keys need to stop being the default control surface.
x402 provides the quote-pay-retrieve flow.
ERC-8004 provides identity and a public record that can evolve into a reputation.
xgate provides discovery, so the market no longer relies on private lists.

The Router provides cross-provider access to USDC inference, making the agent’s operating budget programmable. In practice, the goal is to cover the compute categories agents actually buy: LLM inference, image generation, and video generation, with sandboxed compute on the roadmap. The Router builds on an x402 Upto-style scheme that targets low latency by reducing the extra payment round-trip time, so agents can pay for compute without turning every call into a slow handshake.

Lucid integrates all of this into an SDK and runtime, so builders ship services rather than rebuilding commerce plumbing in every repository.

This matters for general AI because it reduces friction in standard developer workflows.
It also enables a path where agents pay for tools in the background while products still feel like standard SaaS.

So, Agentic commerce has developed. What else does the stack need?

Microtransactions on layer two networks are increasing, but this increase does not come only from agent commerce.
ERC-8004 activity can also grow for other reasons, because it indexes public endpoints and identities, not “agentic behavior” itself.
To move from “more registrations” to real agent commerce, the ecosystem needs fewer dead listings and more reliable, standards-conforming services that agents can reach and call without hard-coded URLs.

The next milestones look like this.
Discovery becomes a default workflow, not a niche index.
Conformance tests become normal, so an agent can verify schema, auth, pricing, retries, and error handling before it pays.
Reputation shifts from “who exists” to “who stays up, answers fast, and returns correct data.”
Payment moves from per-request fragility to production patterns such as balances, batching, and clear refund semantics.
Wallet UX becomes boring and safe, with budgets, policies, and auditing that product teams can ship without crypto-only assumptions.

When those pieces land, the story stops being “agent commerce is possible” and becomes “agent commerce is the cheaper default than rebuilding the tool yourself.”

What is the takeaway?

Just several months ago, there was an idea of a stack, as described in Not a Lucid Web3 Dream Anymore: x402, ERC-8004, A2A, and The Next Wave of AI Commerce | HackerNoon.
The last month produced a clearer market-shaped story.
Discovery moved closer to a default workflow through xgate.
Shipping moved closer to a repeatable pattern through Lucid Agents releases and the skills market.
Langoustine provides a concrete case of an agent paying for its own work loop, shipping paid endpoints, and building a public execution record over time.
DayDreams is one concrete implementation of the Agent Experience (AX) direction.
The commerce layer for the agentic internet, where agents autonomously discover, transact, and coordinate with one another.
That is the bridge from crypto AI to general AI.
It is neither a new coin nor a new chatbot.
It is a tool economy in which paid calls, discovery, and identity begin to look like standard infrastructure.

Where can we go from here?

If you zoom out, OpenClaw looks like an early candidate for an “AI operating system” layer.
It runs long-lived agents that can operate a computer, keep state, use tools, and recover from failures, which makes it closer to full computer usage than most agent demos today.

The race to own this AI operating system layer has started.
The next default “user interface” for many workflows can be an optimized Linux setup running an OpenClaw-style computer-use agent rather than a traditional desktop-first OS experience.
Security and isolation still block mainstream adoption.
A practical approach is a dedicated local machine that combines Nix-style configuration with an OpenClaw-style harness.
Configuration files define processes, reboot recovery, and automatic restarts, and the agent can run tasks while the system can revert when changes break.
This setup creates a controlled playground for AI-driven automation.

Once an agent stops being a demo and starts being a system, the question shifts from “What can you build?” to “What can you maintain?”.
Models already let small teams ship fast.
The hard part stays on on-call ownership, bug triage, and payment disputes once real users and real money enter the loop.
That is where agent commerce stops being a crypto demo and starts looking like infrastructure.

If agents do real work, they need settlement paths that product teams can operate.
One possible direction is to charge machine clients through standard billing rails, for example, PaymentIntents-style flows, so “pay per call” becomes as normal as subscriptions and invoices.
When that becomes boring and reliable, paid tool use becomes the default option instead of rebuilding the tool yourself.

AI optimizes the world as it is.

Crypto builds new rails that the current world lacks.
When these two meet, the “app layer” becomes less important than the service layer.
You stop browsing apps and start delegating tasks.
Agents search, verify, pay, and call services in the background.

It's still early.

But the direction is clear.

The first contact has been made.

The post From “Crypto AI” to general AI: Do AI agents dream of electric langoustines? appeared first on foojay.

As part of my 2026 learning goals around Java on RISC-V (see this post about x86 versus ARM versus RISC-V), I've asked various suppliers to send me evaluation boards. I already published these:

• LattePanda IOTA (x86)
• OrangePi 5 Ultra (ARM) and OrangePi RV2 (RISC-V)
• VisionFive 2 Lite (RISC-V)
• In this post: BeagleBoards (ARM and RISC-V)

I got all these boards for free, but what I write here and show in the video is not controlled by BeagleBoard or one of the other suppliers.

ARM versus RISC-V?

ARM and RISC-V represent two different approaches to processor design. ARM is the established player we know from, e.g., the Raspberry Pi's. It's mature, and has a huge ecosystem of tools and support built over decades. RISC-V is the open-source alternative, free from licensing restrictions and fully transparent. While ARM still leads in performance and tooling today, RISC-V is catching up fast. The real difference isn't just about speed. It's about openness and flexibility. With RISC-V, you're not locked into a vendor's ecosystem, and you have complete visibility into how your hardware works.

BeagleBoards

BeagleBoard has a wide range of single-board-computers in Raspberry Pi-like and Arduino-like formats. Here's how the BeagleBoards I received, compare to the latest Raspberry Pi's:

Test Boards

I received the following boards.

BeagleY-AI

BeagleY®-AI is a low-cost, open-source, community-supported development platform for developers and hobbyists in a familiar form-factor compatible with accessories available for other popular single board computers. Users benefit from BeagleBoard.org-provided Debian Linux software images with a built-in development environment and the ability to run artificial intelligence applications on a dedicated 4 TOPS co-processor along with real-time I/O tasks on a dedicated 800MHz microcontroller. BeagleY®-AI is designed to meet the needs of professional developers and classroom-environments alike being affordable and easy-to-use, while being open source hardware such that developers barriers are eliminated to how deep the lessons can go or how far you can take the design in practical applications.

• Product page
• Documentation

BeagleV-Fire

BeagleV®-Fire is a revolutionary single-board computer (SBC) powered by the Microchip’s PolarFire® MPFS025T 5x core RISC-V System on Chip (SoC) with FPGA fabric. BeagleV®-Fire opens up new horizons for developers, tinkerers, and the open-source community to explore the vast potential of RISC-V architecture and FPGA technology. It has the same P8 & P9 cape header pins as BeagleBone Black allowing you to stack your favorite BeagleBone cape on top to expand it’s capability. Built around the powerful and energy-efficient RISC-V instruction set architecture (ISA) along with its versatile FPGA fabric, BeagleV®-Fire SBC offers unparalleled opportunities for developers, hobbyists, and researchers to explore and experiment with RISC-V technology.

• Product page
• Documentation

BeagleV-Ahead

BeagleV®-Ahead is an open-source RISC-V single board computer (SBC) with BeagleBone Black cape header pins allowing you to stack your favorite BeagleBone cape on top to expand it’s capability. Featuring a powerful quad-core RISC-V processor, BeagleV®-Ahead is designed as an affordable RISC-V enabled pocket-size computer for anybody who want’s to dive deep into the new RISC-V ISA.

• Product page
• Documentation
• Linux Kernel
• Flashing Ubuntu OS
• BeagleV-Ahead Ubuntu 2023-07-05
• BeagleV-Ahead Quick Start

PocketBeagle 2

PocketBeagle 2 is an upgraded version of the popular PocketBeagle, designed as an ultra-compact, low-cost, and powerful single-board computer (SBC). Targeted at developers, students, and hobbyists, PocketBeagle 2 retains the simplicity and flexibility of its predecessor while delivering enhanced performance and expanded features to support modern development needs. PocketBeagle 2 is ideal for creating IoT devices, robotics projects, and educational applications. Its small form factor and low power consumption make it a versatile platform for embedded development, whether prototyping or deploying at scale.

• Product page
• Documentation
• PocketBeagle TechLab: Designed from lessons-learned in teaching hundreds of individuals getting their first introduction to programming, Linux, and ultimately hacking the kernel itself.

First Tests

The easiest way to get started with a BeagleBoard and burn the latest OS on an SD card, is the BeagleBoard Imaging Utility, available for Windows, macOS and Linux. This is the first supplier of SBC's that provides such a tool that is comparable to the Raspberry Pi Imager Tool. It's a crucial factor to get started with a new type of SBC, and BeagleBoard has done a great job in making this tool available.

BeagleY-AI (ARM Processor)

This board delivered the smoothest experience of all four BeagleBoards. Using BeagleBoard's excellent Imaging Utility, I created an SD card with the latest OS, providing the username and password I want to use via the settings. With the SD card installed, I connected it via micro HDMI and USB, and booted into a desktop environment within minutes. After the standard update and `upgrade, I installed SDKMAN, Java (Azul Zulu 25.0.2 with JavaFX support), and JBang. The JavaFX test application from the Pi4J JBang repository ran flawlessly, confirming that both Java and JavaFX work perfectly on this ARM-based board. It's very comparable to the Raspberry Pi 5, even sharing similar connector placement, making it an excellent choice for Java development.

sudo apt update
sudo apt upgrade
sudo apt install zip
curl -s "https://get.sdkman.io" | bash

# Close the terminal and open a new one
sdk install java 25.0.1-zulu-fx
sdk install jbang

# Close the terminal and open a new one
git clone https://github.com/Pi4J/pi4j-jbang.git
cd pi4j-jbang
cd javafx
jbang HelloJavaFXWorld.java

BeagleV-Fire (RISC-V Processor)

This board proved challenging due to my Raspberry Pi habits. I initially created an SD card using the Imaging Utility, not realizing the board already has Ubuntu pre-installed in its eMMC storage. Unfortunately, it's running Ubuntu 23.04, which is no longer maintained, preventing me from updating or installing Java through the package manager. The correct approach requires connecting the board via USB to my computer and flashing the eMMC directly using the Imaging Utility's device mode, but I haven't successfully completed this process yet. While Java RISC-V builds exist and should theoretically work, I need to resolve the OS update issue first before confirming Java compatibility.

Default username and password are beagle:temppwd.

% ssh beagle@10.120.10.11
Ubuntu 23.04

BeagleBoard.org Ubuntu 23.04 Console Image 2023-10-19
Support: https://bbb.io/debian
default username:password is [beagle:temppwd]

BeagleV-Ahead (RISC-V Processor)

This larger RISC-V board presents its own unique challenges. Unlike modern boards, it requires a traditional 5-volt barrel connector instead of USB-C for power. I successfully connected to it via SSH over my network, but discovered it runs a custom Linux distribution specifically built for its processor, one I didn't recognize and couldn't identify as Debian or Ubuntu-based. The apt package manager doesn't function on this distribution, leaving me unable to install Java through standard methods. While Java RISC-V builds should theoretically be compatible, I need to dive deeper into the documentation to understand this custom distribution and determine the proper installation approach.

Default username is root without a password.

# cat /etc/*-release
commit-id:52fbe8443ea11d7e0abf958a8e2a202d67ef40c1
ID=thead-c910
NAME="THEAD C910 Release Distro"
VERSION="1.1.2"
VERSION_ID=1.1.2
PRETTY_NAME="THEAD C910 Release Distro 1.1.2"
BUILD_ID="20230609164851"
HOME_URL="https://occ.t-head.cn/"

# apt search openjdk
Sorting... Done
Full Text Search... Done

# apt install java
Reading package lists... Done
Building dependency tree... Done
E: Unable to locate package java

PocketBeagle 2 2 (ARM Processor)

This tiny ARM-based board uses the Cortex A53 processor (the same as the BeagleY-AI), which means Java should run without issues since ARM Java distributions are readily available. I haven't tested it yet, but I'm confident it will work. The exciting part is the included Tech Lab kit with buttons and RGB LEDs that mount directly on top of the board, making it an ideal platform for coding clubs and educational settings where you want to combine programming with physical computing experiments. This compact form factor paired with interactive hardware makes it a promising board for hands-on Java experimentation.

Conclusion

My congratulations to BeagleBoard for their documentation website and Imaging Utility! That really sets them apart from other single-board computer suppliers I tested before. Java on BeagleY-AI runs within minutes of starting my tests, and I'm confident I'll be able to use it for further experiments.

For the other boards, I'll need some more time to figure out how to proceed. The BeagleV-Fire needs a newer version of Ubuntu, and the Linux version on the BeagleV-Ahead is still a mystery to me...

As I set my goals for 2026 to learn more about different types of single-board-computers that's a perfect conclusion. It's just the beginning of 2026, so I have still more than 10 months this year to achieve my goal

The post First Test of Java on BeagleBoards (ARM and RISC-V) appeared first on foojay.

As part of my 2026 learning goals around Java on RISC-V (see this post about x86 versus ARM versus RISC-V), I've asking various suppliers to send me evaluation boards. I already published about two and adding a third one now:

• LattePanda IOTA
• OrangePi 5 Ultra and OrangePi RV2
• In this post: StarFive VisionFive 2 Lite

I got all these boards for free, but what I write here and show in the video is not controlled by StarFive or one of the other suppliers.

Why RISC-V?

RISC-V is an open standard instruction set architecture, driving by the community. Unlike architectures from ARM, Intel, and AMD which must be licensed. This openness has lead to innovation across the industry, and boards like the VisionFive 2 Lite make it accessible to developers like us who want to experiment with (Java) applications on alternative architectures.

StarFive VisionFive

The VisionFive from StarFive is a range of affordable boards for your first steps into the RISC-V world. Here's how the VisionFive's compare to the latest Raspberry Pi's:

Test Board

I received a VisionFive 2 Lite for testing:

• Product page
• Documentation
• Quick Start Guide
• Ubuntu Images and other software
  • Used: ubuntu-24.04.3-preinstalled-desktop-riscv64+vf2-lite.img

I burned the Ubuntu image to an SD card, but if you want to use eMMC, you can follow these instructions: Flashing OS to Onboard eMMC (eMMC Version). This OS has the pre-configured account user with password starfive.

On the Ubuntu website, more installation instructions are available for a lot of different boards, e.g. for the VisionFive 2 Lite.

Getting Started

Hardware Setup

The board arrived well-packaged, and has a very similar layout to the Raspberry Pi 5. Biggest connection difference: one big HDMI connector instead of two micro-HDMI ports.

Installing Ubuntu

StarFive provides several OS options, but I opted for Ubuntu 24.04.3 LTS Desktop for RISC-V. The process is well-documented:

1. Download the image: ubuntu-24.04.3-preinstalled-desktop-riscv64+vf2-lite.img from the StarFive GitHub releases

2. Burn the image to an SD card (I used the Raspberry Pi Imager tool)

3. First boot uses user as the username with password starfive

4. The first boot took a bit longer than expected before the desktop appeared. Once up, the system felt responsive for basic tasks, though noticeably slower than a Raspberry Pi 5.

Java Installation and Testing

This is where things get interesting. RISC-V support in the Java ecosystem has improved significantly, but it's still relatively new compared to ARM and x86_64.

Installing Java

Ubuntu for RISC-V includes OpenJDK in the repositories, so it can be installed with sudo apt install, after you have done update and upgrade:

sudo apt update
sudo apt upgrade
sudo apt install openjdk-25-jdk

This installed OpenJDK 25.0.1, built for RISC-V architecture. The installation was straightforward, taking only a few minutes including dependencies. To verify the installation:

java -version

Simple Java Tests

I just wanted to quickly try out a few existing test scripts, and used my JBang project in the Pi4J repositories. As you can see in the video "plain" Java and libraries work as expected. Pi4J and JavaFX were not successful, but also that was expected. I will try Pi4J after the release of its version 4, when it uses the Foreign Function and Memory (FFM) API. As we installed a "normal OpenJDK Build", which doesn't include the JavaFX dependencies, we can't run the example.

Conclusion

The VisionFive 2 Lite is an intriguing board for Java developers curious about RISC-V. At around 60€, it's an accessible way to explore this "other type of" architecture without significant investment. The performance isn't going to compete with a recent Raspberry Pi, but that's not really the point. My first goal was to find out if Java works on it (of course!), and how easy it us to use. And of course, to feed my curiosity to learn new stuff...

Later more, when I try to get Pi4J working on it!

If you're working on similar projects or have experience with Java on RISC-V, I'd love to hear about it. Feel free to reach out through Mastodon or the Foojay.io community.

The post First Test of Java on the VisionFive 2 Lite (RISC-V) appeared first on foojay.

As part of my 2026 learning goals around Java on Single Board Computers and RISC-V (see this post about x86 versus ARM versus RISC-V), I've been asking various suppliers to send me evaluation boards. After testing the LattePanda IOTA, I received two boards from OrangePi to evaluate: the OrangePi 5 Ultra (ARM) and the OrangePi RV2 (RISC-V).

I got both boards for free, but what I write here and show in the video is not controlled by OrangePi or any other supplier.

OrangePi Lineup

OrangePi offers a diverse range of single board computers at various price points. For this table, I focused on the two boards that I received:

The OrangePi 5 Ultra is a high-end board with the powerful RK3588 SOC (same chip used in many Android TV boxes and mini PCs), while the OrangePi RV2 is their budget RISC-V with a Kylin X1 processor.

Test Boards

I received two boards, two eMMC modules, and two power supplies. So everything to get me started! But to speed things up, I decided to use SD cards for the Operating System and will use the eMMC modules later, which should give a significant better performance.

OrangePi 5 Ultra

More info about the OrangePi 5 Ultra is available here:

• Product page
• Documentation
• User Manual
• Ubuntu Images

I used the image: Orangepi5ultra_1.0.0_ubuntu_jammy_desktop_xfce_linux6.1.43.

OrangePi RV2

More info about the OrangePi RV2 is available here:

• Product page
• Documentation
• User Manual
• Ubuntu Images

I used the image: Orangepirv2_1.0.0_ubuntu_noble_desktop_gnome_linux6.6.63.

Getting Started

Hardware Setup

Both boards arrived well-packaged. The OrangePi 5 Ultra looks almost identical as a Raspberry Pi 5. It has an excellent build quality with very similar connecters, except it has a full HDMI in and out, compared to two micro HDMI out on the Raspberry Pi 5. The RV2 has again the same size as a Raspberry Pi, but with a completely different port layout and only 26 GPIO pins compared to 40 on the Raspberry Pi 5 and OrangePi 5 Ultra. Both boards have a detachable Wi-Fi antenna-cable.

Installation for both followed a similar pattern: download the Ubuntu image from OrangePi's Google Drive, flash to microSD, and boot.

Java Installation and Testing

OrangePi 5 Ultra (ARM)

For the ARM-based 5 Ultra, I wanted to test the full Java stack including JavaFX. With SDKMAN I could quickly install a JDK and JBang.

Installing SDKMAN

Run the curl command to install SDKMAN, and open a new shell, or use the source command to activate SDKMAN:

curl -s "https://get.sdkman.io" | bash
source "$HOME/.sdkman/bin/sdkman-init.sh"
sdk version

SDKMAN provides easy access to multiple Java distributions and versions. For this board, I installed Azul Zulu 25 with JavaFX:

sdk install java 25.0.1.fx-zulu
sdk install jbang

Testing with Pi4J Examples

I cloned my JBang project from the Pi4J repositories to run some tests:

git clone https://github.com/Pi4J/pi4j-jbang.git
cd pi4j-jbang

The plain Java examples worked perfectly. The JavaFX example also ran smoothly, demonstrating that the RK3588 GPU is well-supported in Ubuntu. The board feels very responsive with these first, quick tests.

OrangePi RV2 (RISC-V)

The RV2 was more challenging, as expected with RISC-V hardware.

Java Installation

SDKMAN doesn't yet have RISC-V support to install Java. I made a GitHub issue and first pull request, and will try to get this moving. I hope this will help more Java developers to experiment with RISC-V.

For now, the Ubuntu repositories are the way to go:

sudo apt update
sudo apt upgrade
sudo apt install openjdk-25-jdk

This installed OpenJDK 25 for RISC-V (but without JavaFX dependencies).

Testing Basic Java

I ran the same JBang examples that worked on the OrangePi 5 Ultra. Plain Java code executed without issues, but JavaFX examples failed as expected due to missing dependencies. The same issues with Pi4J are reported regarding user rights, something to investigate in the future.

OrangePi RV2 Performance Comparison

Phoronix conducted comprehensive benchmarks comparing the OrangePi RV2 with Raspberry Pi boards. Their Java SciMark 2.2 tests show the RV2 is 2-7 times slower than the Raspberry Pi 5 depending on the workload.

The overall benchmark results paint a clearer picture:

The RV2 scores lower than both the Raspberry Pi 4 and 5 across most tests. This isn't a surprise because RISC-V is still maturing, and the Ky X1 is an early implementation. The 8 cores help with parallel workloads, but single-threaded performance lags behind ARM equivalents.

In contrast, the OrangePi 5 Ultra performs exceptionally well and should be comparable to the Raspberry Pi 5 performance thanks to the powerful RK3588 SOC. But that's an other personal goal for 2026, setting up a good benchmark to compare Java performance on various boards...

Conclusion

These two boards represent vastly different approaches. The OrangePi 5 Ultra is a premium board that competes directly with high-end single-board and desktop computers for many tasks. It's more expensive than a Raspberry Pi but delivers impressive performance. Thanks to SDKMAN and the various Java tools that work just as wel as on any other type of Linux computer, including JavaFX, it's an attractive platform for serious development work for a low price.

The OrangePi RV2, on the other hand, is clearly a budget RISC-V board for experimenters. The performance doesn't match ARM boards in the same price range (yet?), but that's not really the point. It's an affordable way to explore RISC-V, contribute to ecosystem development, and prepare for a future where RISC-V becomes more competitive.

For Java developers specifically: if you need a powerful ARM board for actual work, the OrangePi 5 Ultra is worth considering. If you're curious about RISC-V and want to help mature the Java ecosystem on this architecture, the RV2 provides a low-cost entry point.

My testing continues with more RISC-V boards coming soon! If you're working on similar projects or have experience with Java on OrangePi boards, I'd love to hear about it. Feel free to reach out through Mastodon or the Foojay.io community.

The post First Test of Java on the Orange Pi (ARM and RISC-V) appeared first on foojay.

Ever since I started my #JavaOnRaspberryPi journey in 2019, which resulted in my book "Getting Started with Java on the Raspberry Pi", I've been fascinated with these tiny, inexpensive computers. For 2026, I've set one of my goals to experiment with Java on various Single-Board Computers (SBC), going beyond my "Raspberry Pi comfort zone." The market is flooded with SBCs ranging from budget boards (tens of euros) to powerhouses (hundreds of euros). One of the reasons of this price range is the difference between the processors they use. Raspberry Pi uses an ARM processor, but RISC-V is gaining momentum, while Intel maintains its presence. So before I start experimenting, now is the perfect time to compare these three processor families and understand their differences.

This post is just a "comparison of facts." I was so lucky to receive a few different boards at the end of 2025, so expect more posts later when I run my first tests on them!

On the picture:

• Raspberry Pi 4 (ARM)
• Orange Pi 5 Ultra (ARM)
• Orange Pi RV2 (RISC-V)
• VisionFive 2 Lite (RISC-V)
• LattePanda IOTA (x86)

Let's compare the different types of processors used for these SBCs.

ARM: Efficient by Design

Arm Holdings plc (originally "Acorn RISC Machine", later "Advanced RISC Machines") is a British semiconductor and software design company. There primary business is the design of central processing unit (CPU) cores that implement the ARM architecture family of instruction sets. They don't manufacture the chips, but design the architecture and license it to others. This means that an application written for a Qualcomm Snapdragon processor should also work on a Samsung Exynos or Apple's M-series chip because they speak the same "ARM language".

The ARM standardization has resulted in billions of ARM chips shipped every year, countless apps optimized for ARM, and a development community that spans the globe. The same efficiency principles that make ARM perfect for smartphones are exactly what make it ideal for single board computers like the Raspberry Pi. Both need to do a lot with limited power.

The ARM architecture uses a RISC (Reduced Instruction Set Computer) with a focus on power efficiency. The instruction set is relatively simple, with most instructions executing in a single clock cycle. ARM processors typically feature:

• Power consumption: 1-15W for typical SBC implementations
• Instruction set: 32-bit in ARMv1-ARMv7, mixed 32/64-bit in ARMv8, 64-bit in ARMv9
• Licensing model: Arm Holdings is the owner and it's primary business is selling licenses to manufacturers like Broadcom, Qualcomm, Apple,...

ARM on Mobile Devices

If you're reading this on a smartphone, there's a 99% chance you're holding an ARM-powered device right now. ARM has achieved almost total dominance in the mobile market. Every major manufacturer uses ARM architecture for their mobile chips.

The reason? Power efficiency! The RISC architecture in an ARM processor, allows smartphones to deliver impressive performance with low power consumption, making sure your battery lasts a day...

ARM on Raspberry Pi

The most popular SBC is the Raspberry Pi, and it uses an ARM processor, which is integrated in the System-On-Chip (SOC) combining CPU, GPU, memory controller, USB controller, etc. For instance:

• Raspberry Pi 1: BCM2835 SOC with 1x ARM1176JZF-S @ 700Mhz ARMv6
• Raspberry Pi Zero 2: BCM2710A1 SOC with 4x Cortex-A53 @ 1000Mhz ARMv8
• Raspberry Pi 4: BCM2711 SOC with 4x Cortex-A72 @ 1800Mhz ARMv8
• Raspberry Pi 5: BCM2712 SOC with 4x Cortex-A76 @ 2400Mhz ARMv8

As you can see, throughout the history of Raspberry Pi boards, newer ARM versions have been introduced with more cores and higher speeds. With the change from ARMv6 to ARMv8, it also became possible to switch to a 64-bit operating system.

ARM on Cloud Computing

ARM can also be found in the cloud! AWS uses it for their Graviton Processors that are ARM-based chips specifically designed for cloud workloads, and they're delivering impressive results:

• Up to 40% better price-performance compared to x86 instances.
• Using up to 60% less energy.

Many AWS customers use Graviton to run everything from application servers and microservices to databases and high-performance computing workloads.

ARM in the Apple M-Series

Perhaps the most impressive proof that ARM can compete with x86 at the high-end came in 2020 when Apple announced its M1 chip. It's an ARM-based processor for Mac computers. At that time, it was a huge gamble, as they ditched Intel processors that had powered Macs for over 10 years in favor of their own ARM-based silicon.

But the results were revolutionary! The M1 delivered performance that matched or exceeded Intel chips while using a fraction of the power. An M1 Mac Mini draws just 39 watts at maximum load compared to 122 watts for the 2018 Intel-based Mac Mini with a 6-core Core i7. The secret is Apple's System-on-Chip design with Unified Memory Architecture, where the CPU, GPU, Neural Engine, and memory all share the same memory pool on a single chip. This tight integration, combined with ARM's efficient instruction set, allows the M-series to deliver desktop-class performance in fanless laptops.

Each time I need to use a Windows laptop, I'm overwhelmed by the fan noise and the heat coming out of it. My M1 MacBook Air, in contrast, seems to have no fan at all and is completely silent, even when compiling code or running multiple Java applications. This isn't just about comfort but is proof of ARM's power efficiency.

Apple's success with M-series chips has proven that ARM isn't just for mobile and embedded. It can go head-to-head with traditional desktop processors, and often wins on both performance and efficiency.

Java on ARM

What I love about ARM for Java development is the mature ecosystem. The JVM has been heavily optimized for ARM, and the Pi4J library (designed for the Raspberry Pi) works seamlessly because the hardware support is rock-solid.

The entire Java ecosystem (OpenJDK, popular frameworks, and build tools) works seamlessly on ARM instances, including Apple's M-series and AWS Graviton. This means the same ARM-optimized Java code you're running on your Raspberry Pi could theoretically scale all the way up to massive cloud deployments on AWS Graviton. The architecture that powers your 20-euro Raspberry Pi Zero 2 is the same one handling enterprise-scale workloads in data centers. That's the beauty of ARM's versatility. It ranges from microcontrollers, to smart phones, to embedded systems, to cloud infrastructure, all with consistent tooling and development practices.

x86: Running the Same Code Since 1985

The x86 architecture of Intel (x86-64/AMD64 for modern systems) takes a different approach. It's a CISC (Complex Instruction Set Computer) architecture with a rich, complex instruction set that's evolved over decades.

Key characteristics:

• Power consumption: 10-65W for SBC-class processors (like the Atom or Celeron series)
• Instruction set: 32-bit and 64-bit
• Compatibility: Can run decades-old x86 software without modification

Intel-based SBCs like the LattePanda IOTA offer complete x86 compatibility. If you need to run legacy Windows applications or x86-specific software, Intel is your only choice. However, you pay for this with higher power consumption and heat generation.

For Java developers, Intel means maximum compatibility with desktop tooling and slightly better performance in some JVM workloads due to decades of JIT optimization for x86.

Decades of Desktop, Laptop, and Server Dominance

For most computing history, Intel's x86 architecture has been synonymous with personal computers. From the 1990s through the 2010s, if you were using a desktop, laptop, or server, you were almost certainly running on Intel silicon. At its peak, Intel controlled over 99% of the server market and dominated desktop and laptop sales with an overwhelming market share. The x86 architecture became the standard not just because of Intel's engineering prowess, but because of decades of backward compatibility. Newer x86 processors could run programs written for processors from the 1980s. This created an enormous software ecosystem where every application, every operating system, every driver was optimized for x86.

When Apple switched from PowerPC to Intel in 2006, it was validation that x86 was the only serious choice for high-performance computing (at that time). Intel's dominance extended into data centers and cloud computing, where their Xeon processors powered the infrastructure behind almost every major web service.

AMD versus Intel: Two Implementations of x86

While Intel dominated x86 for decades, Advanced Micro Devices, Inc. (AMD) has been its primary competitor since the 1980s. The interesting story here is that both companies make x86 processors, but through different licensing arrangements. In the early 1980s, IBM required Intel to license x86 to a second manufacturer (AMD) to avoid single-supplier risk. Since then, both companies have independently designed their own processor architectures that implement the x86 instruction set. This means a program compiled for x86 will run on both Intel and AMD processor, they speak the same language.

However, the internal designs differ significantly. AMD innovated by creating the x86-64 (AMD64) instruction set in 2003, extending x86 to 64-bit computing while maintaining backward compatibility with 32-bit software. Intel's attempt at 64-bit (Itanium/IA-64) failed in the market, so Intel ended up licensing AMD's 64-bit extensions, which means, today, both companies' processors use AMD's 64-bit architecture underneath! The competition between them has been hard... AMD's recent Ryzen processors have challenged Intel's market dominance, particularly in desktop and server markets where AMD has gained significant ground. For developers and users, the practical differences come down to performance per watt, core counts, cache sizes, and pricing rather than fundamental compatibility. Your Java code will run on either.

Intel's Attempt at the Small Form Factor: NUC and x86 SBCs

Intel didn't ignore the small form factor market. With the NUC (Next Unit of Computing) line launched in the early 2010s, Intel attempted to bring x86 architecture into the compact computing space. NUCs were 4x4 inch mini PCs powered by Intel processors, offering desktop-class performance in a palm-sized package. Intel also produced x86-based single board computers for industrial and embedded applications. However, these Intel-based SBCs faced fundamental challenges compared to ARM competitors like the Raspberry Pi, with power consumption being the critical issue. An Intel NUC typically draws 10-20 watts under load compared to just 2-4 watts for a Raspberry Pi 4.

Intel boards require active cooling with fans, adding noise and complexity. Price was another barrier: NUCs started around $200-300 (often without RAM or storage), while a complete Raspberry Pi setup cost under $100. Most importantly, Intel's x86 SBCs lacked the GPIO pins and hardware interfacing capabilities that made ARM boards so popular for electronics projects and IoT applications.

In 2023, Intel discontinued the NUC line entirely. But many other companies are still building x86 SBCs for small factor desktop systems, Network-Attached Storage (NAS), and Internet of Things (IoT) devices. And some of these do provide GPIO's (like the LattePanda IOTA).

Java on LattePanda IOTA

As expected, Java runs without issue on an x86 SBC, as I documented in a video and blog post in November 2025. First experiments with Pi4J are unsuccessful because the GPIOs on the IOTA are controlled by an onboard Raspberry Pi RP2040, which must be addressed via a serial link. I will experiment with this in the future...

RISC-V: Open Source Goes Hardware

RISC-V (pronounced "risk five") is the new kid on the block, and it's shaking things up. Unlike ARM and Intel, RISC-V is an open standard, and anyone can implement it without licensing fees. Features of the ARM architecture:

• Power consumption: Varies wildly (1-20W depending on implementation).
• Instruction set: Modular base instruction set with optional extensions.
• Licensing model: Open standard, free to implement.

RISC-V boards like the StarFive VisionFive 2, OrangePi RV2, or BeagleV are becoming more common, but the ecosystem is still maturing.

The big advantage of RISC-V? Complete transparency and customization potential at lower cost.

Java on RISC-V

As I mentioned at the start, one of my goals for 2025 is to dive deeper into Java on RISC-V. This is where things get really exciting, but also really experimental...

The good news is that Java officially supports RISC-V with the OpenJDK RISC-V Port Project and the sources on GitHub > openjdk > riscv-port. Today, you can run Java on RISC-V hardware with:

• Full JVM support: The port includes the Interpreter, C1 (client compiler), and C2 (server compiler)
• All garbage collectors: Epsilon, Serial, Parallel, G1, ZGC, and Shenandoah all work
• Complete tooling: JVMTI, Java Flight Recorder, and other serviceability features
• Desktop support: Even AWT and Swing should work

The port targets the RV64G configuration (64-bit RISC-V with the standard general-purpose extensions), and there's experimental support for vector operations (RVV) and compressed instructions (RVC). Builds for Ubuntu of Java 17, 21, and 25 are available from Adoptium.

I was not able to test this myself yet, but as you can see on the pictures at the beginning of this post, they are waiting right beside me to be powered on...

Performance and Ecosystem Maturity

But let's be honest, as far as I understand, RISC-V is not yet competitive with ARM in terms of performance. The current RISC-V boards like the StarFive VisionFive 2 are significantly slower than equivalent ARM boards. We're talking 2-3x slower than a Raspberry Pi 4 running at the same clock speed.

As RISC-V is a community project, things evolve slower compared to Intel, AMD, ARM,...

Hardware limitations: Current RISC-V cores run at lower clock speeds. The hardware simply isn't as optimized yet.

Software ecosystem: While the JVM port is complete and functional, it lacks the years of optimization that the x86 and ARM port has received. There are fewer intrinsics (hand-optimized assembly routines) for common operations like cryptography, string manipulation, and mathematical functions. This means the JIT compiler can't take full advantage of RISC-V-specific instructions yet.

Compiler maturity: GCC and LLVM support for RISC-V is improving rapidly, but they don't generate code that's as optimized as what they produce for ARM or x86. This affects both native code and the performance of the JVM itself.

Why Java and RISC-V Are a Perfect Match (In Theory)

Despite the current performance gap, there are reasons why Java and RISC-V make sense together:

Both are open: Java is open-source through OpenJDK, and RISC-V is an open Instruction Set Architecture (ISA). No licensing fees, no vendor lock-in, complete transparency. For projects where you want full control over both hardware and software, this is incredibly powerful.

Platform independence: Java's "write once, run anywhere" philosophy aligns perfectly with RISC-V's goal of providing a standard, open instruction set. Your Java application doesn't care whether it's running on ARM, x86, or RISC-V.

Embedded focus: Both Java and RISC-V are targeting the embedded and IoT space. As RISC-V boards become more common in industrial applications, having mature Java support will be crucial.

Community-driven: Both ecosystems thrive on community contributions and collaboration. The work being done to optimize Java for RISC-V benefits everyone, and all improvements go upstream to OpenJDK.

Pi4J on RISC-V

This is the main reason I want to try out RISC-V with Java! Pi4J will soon be released as V4 with the new Foreign Function and Memory (FFM) API which is available since Java 22. Because of this FFM API, the library should be compatible with "any" Linux system with GPIOs. Pi4J was originally designed for the Raspberry Pi, but this new plugin should open it for more boards. And that's exactly what I'm going to try out in 2026!

Does it work? No idea. Stay tuned for my 2026 experiments!

Java Development Considerations

As a Java developer working with embedded systems, here's what matters:

• ARM
  • Excellent JVM support (Many distributors, like Azul, provide ARM builds)
  • Pi4J and native libraries are mature and well-tested
  • Best power consumption for long-running Java applications
  • GPIO and peripheral access is standardized (at least on Raspberry Pi)
• x86
  • Maximum JVM compatibility, every Java feature works
  • Better performance for computationally intensive tasks
  • Higher power consumption means active cooling often required
• RISC-V
  • OpenJDK support is improving but still experimental
  • Not sure yet if Pi4J works on RISC-V
  • Great for contributing to open-source JVM development
  • Exciting to experiment with new hardware platforms

My 2026 Experiments

RISC-V is promising, improving rapidly, but not yet ready to replace established platforms for most use cases. However, for developers who value openness, want to experiment with cutting-edge hardware, or need to avoid licensing constraints, RISC-V with Java is an exciting frontier.

So this year, I plan to get hands-on experience with Pi4J on more SBCs by:

• Trying out OrangePi 5, OrangePi RV2, VisionFive 2 Lite, and more similar boards
• Running real Java applications and benchmarking performance
• Exploring the current state of hardware interfacing from Java
• Sharing and contributing where I can

Watch my blog for new posts, and subscribe to my LinkedIn, Bluesky, Mastodon, and YouTube channel for updates!

The post Java on Single Board Computers: x86 vs ARM vs RISC-V appeared first on foojay.

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

1. 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.

2. 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.

3. 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.

4. 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.

5. 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:

1. An agent receives a task.
2. The agent queries XGATE to find relevant endpoints (data, signals, tools).
3. The agent pays per call by x402.
4. 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.

1. Personal autonomy is now open to anyone shipping paid agentic endpoints.
2. Reputation and volume will pool around useful endpoints, putting early movers in front when traffic jumps.
3. 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.

After years of experimenting with Raspberry Pi boards, Java, JavaFX, and Pi4J to control electronics, I wanted to explore whether my knowledge and experience could be applied to similar boards from other providers. There are many alternatives available these days, based on ARM, Intel processors, and RISC-V architectures.

I reached out to several suppliers to see if I could get evaluation copies, and I'm happy to share that I received my first box from DFRobot containing the LattePanda IOTA.

Unboxing the LattePanda IOTA

The box contained multiple smaller boxes, but the most important one was the LattePanda IOTA board itself, based on an Intel Twin Lake N150 quad-core processor (up to 3.6GHz). It has a clear warning on the packaging: "Do not operate without a heatsink". This thing will definitely get hot if you ignore that warning I guess

The board is a bit bigger than a Raspberry Pi and appears very well-made. It has:

• A GPIO header (similar to Raspberry Pi, though the pin numbering is different)
• Network connection
• Connections for storage options and other expansions
• Three USB ports
• A full-size HDMI connector (more convenient than the mini or micro HDMI on Raspberry Pi)

In the same box, I also received:

1. M2 expansion board: for extra storage
2. Active cooler: essential to prevent overheating
3. UPS hat: for battery backup functionality
4. Power over Ethernet shield: handy, will test later
5. 4G LTE module with SIM card support

The cooling fan has a nice logo and excellent build quality. The PoE shield connects directly to a new network connector on the board, unlike Raspberry Pi expansion boards that use the Pi's existing network connection.

Assembly

Following the documentation, I applied thermal paste to the processor, attached the cooling fan, and connected the M2 expansion board.

Setting Up The Board

First Boot: Windows Pre-installed

After finding the power button, the LattePanda logo appeared on screen, and... Windows started booting. Windows was pre-installed, though I'm not sure if this is default or just for evaluation units. Either way, I immediately noticed 100% CPU usage, the exact reason I left Windows long ago, as I never understood that it's an ongoing problem with Windows... Memory usage was also pretty high.

This thing definitely works with Windows, but I don't use Windows myself. Time to turn this into a Linux device.

Installing Ubuntu

I put the latest Ubuntu system on a USB stick to boot from it, restarted the device, and kept pressing the delete button to enter the BIOS. The system recognized the USB drive immediately. After selecting it and choosing "Save and exit", it booted into Ubuntu installation mode. A few configuration steps later, I had a nice combination: LattePanda running Ubuntu.

Setting Up Java Development

As expected, Java isn't pre-installed in Ubuntu, but several installation options were suggested. However, there's an easier way to prepare a Linux embedded board like this or a Raspberry Pi for Java development: the Pi4J OS repository.

This repository contains scripts to set up boards for Java development, making it easy to have everything prepared and ready to start. There are two scripts available:

1. One for Raspberry Pi
2. One for non-Raspberry Pi boards

Using the second option, curl downloads and executes the script for non-Raspberry Pi boards with the following command:

curl -sL https://raw.githubusercontent.com/Pi4J/pi4j-os/main/script/prepare-for-java-non-rpi.sh | bash

This performs:

• System update
• Installation of extra dependencies for Java and I2C
• SDKMAN installation
• Java installation
• Maven installation
• JBang installation

I also installed Visual Studio Code, the preferred Java editor for this kind of board because it's lightweight and has excellent extensions for Java and JavaFX applications. These are the recommended extensions for Java development:

• Extension Pack for Java: Installs many tools for Java development
• JBang: To execute JBang code directly from VS Code

Testing Java, JavaFX, and Pi4J

I cloned the Pi4J JBang examples project and opened it in Visual Studio Code, to execute code in an easy way.

HelloWorld with JBang

The simple "Hello World" example ran perfectly. There's also an extended example using the Jackson library for JSON parsing, demonstrating how JBang can create single-file applications with dependencies, without needing a full Maven or Gradle project.

JavaFX Test

Since I installed the Java version from Azul with JavaFX included, I could also run a JavaFX demo application. It uses Pi4J to detect the board type, though this only contains methods to detect Raspberry Pi board versions at this moment, so it didn't recognize the LattePanda.

But the application ran smoothly! It showed we're running on a Linux 64-bit system with Java 25. The board wasn't recognized yet as expected, maybe we can in the future add detection tools in the Pi4J library to show the brand or manufacturer information.

Without any extra work, we have a JavaFX application running very smoothly on this board!

Pi4J Test

Now for the fun part: let's see what happens when we run something Pi4J-specific. I tried a project that uses an RGB-LED and changes colors. It compiled, but gave errors about user groups not being configured correctly. This was expected, I've never tried Pi4J on a non-Raspberry Pi single-board-computer before, so I wasn't expecting it to work on the first attempt.

This is something I'll dive into further and post follow-up videos about what can be achieved with the Pi4J library on boards like this.

Performance Check

With htop, I checked the CPU usage. Compared to Windows using 100% CPU, we have here in an idle state almost nothing. There's a lot of room for applications we can run on this board. Great!!!

Conclusion

This was the first quick test, and it only took me about an hour to unbox everything, assemble it, and record this. Very promising results:

• Java runs perfectly
• JavaFX runs very smoothly
• Pi4J not working yet, but that was expected

The next step will be to determine which configuration changes are needed, either at the system level or within Pi4J itself. I'm very happy with this first result. The LattePanda IOTA is a very good-looking board, well-made, and comes with a good fan. You don't hear it running during normal usage. It only ramps up when you start demanding applications.

Promising results! I'm looking forward to experimenting more with this and similar boards to see what's possible with Java(FX) and Pi4J on alternative hardware platforms.

Stay tuned for follow-up videos and blog posts!

The post First Experiments with Java on the LattePanda IOTA: An Alternative to Raspberry Pi? appeared first on foojay.

What if the future of Java depends on who we invite to learn it today?

In this Foojay Podcast, we're diving into something that affects all of us in the Java community: How can we inspire the next generation of developers, and how do we make the developer world more inclusive?

In this episode, you'll hear four incredible guests who are actively working to make tech more accessible and inclusive. First, Daniel De Luca talks about Devoxx for Kids and how they support underprivileged students in IT education. Then Kenny Schwegler shares his insights on how we can actively promote diversity and inclusion in tech. Cassandra Chin, the youngest Java Champion and author, talks about inspiring young coders through hands-on projects and making technology fun. And finally, Igor De Souza discusses his mission to bring Java into Raspberry Pi education and bring more Java into coding clubs worldwide.

These conversations share one message: Talent is everywhere, but opportunity isn't. And we have the power to change that!

YouTube

Podcast Apps

You can listen and subscribe to the Foojay Podcast on:

• Spotify
• Apple Podcasts
• And most others...

Content

01:19 Daniel De Luca

• https://www.linkedin.com/in/danieldeluca/
• Founder Devoxx4Kids
• Activities of Devoxx4Kids
• How to inspire children of all ages to get interested in technology

14:24 Kenny Schwegler

• https://www.linkedin.com/in/kenny-baas/
• How to build inclusive, diverse teams
• How the IT industry became male-focused because of IBM marketing
• Books:
  • https://www.manning.com/books/collaborative-software-design
  • https://learningsystemsthinking.com/

26:07 Cassandra Chin

• https://www.linkedin.com/in/cassandra-chin-developer/
• Inspiring children and parents into technology
• Fun projects to introduce engineering to children
• Book:
  • https://www.amazon.nl/Raising-Young-Coders-Teaching-Programming/dp/B0DVBQZ483
  • 20% Discount code on the Springer website "APAUT"
    • https://link.springer.com/book/10.1007/979-8-8688-1393-1

32:45 Igor De Souza

• https://www.linkedin.com/in/igfasouza/
• Java in code clubs like CoderDojo
• Java in space
• Collecting Java tutorials and courses for children
• Java Catalog on Foojay GitHub
  • https://github.com/foojayio/java-education-catalog
• Pi4J library
  • https://www.pi4j.com/
• HelloWorld magazine:
  • https://downloads.ctfassets.net/oshmmv7kdjgm/6jGvFLH86Ems5AJR84Krsk/3888c571ddc1543c9cdb01ce5eff616d/HelloWorld28.pdf

55:27 Conclusions

The post Foojay Podcast #85: Code, Community, and Opportunity: Making Tech Accessible for Everyone appeared first on foojay.

As described before on Java 21+ Not Working on Raspberry Pi Zero 2, a problem appeared to execute Java code on the Raspberry Pi Zero 2 with OpenJDK 21 or higher. Reason: in OpenJDK 21 the Just-In-Time (JIT) compiler has been improved, but this change doesn’t work correctly on the ARM Cortex-A53 processor as used in the Zero 2. It's another type of processor compared to, for instance, the Raspberry Pi 4 (Cortex-A72) and 5 (Cortex-A76).

A bug was reported in the OpenJDK project: [AArch64] Incorrect result of VectorizedHashCode intrinsic on Cortex-A53 with a solution to become available in a future release.

Let's check, with the latest releases of OpenJDK 21 and 25 if the problem is solved.

Reproducing The Problem

I prepared a Raspberry Pi Zero 2 for the previous blog post, so took it out of my "experimentation box" to reproduce the problem. With the Java 24 version, installed at that time, the problem still exists. You can run java to get its version, but it throws an error when you try to execute any Java code.

$ java -version
openjdk version "24.0.2" 2025-07-15
OpenJDK Runtime Environment Zulu24.32+13-CA (build 24.0.2+12)
OpenJDK 64-Bit Server VM Zulu24.32+13-CA (build 24.0.2+12, mixed mode, sharing)

$ java HelloWorld.java
An exception has occurred in the compiler ((version info not available)). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
java.lang.NoClassDefFoundError: com/sun/tools/javac/jvm/ClassReader$AttributeReader
	at jdk.compiler/com.sun.tools.javac.jvm.ClassReader.initAttributeReaders(ClassReader.java:886)
	...

I also tried the previous version of Zulu 21 (based on OpenJDK 21.0.7, released on April 15, 2025). It has the same problem:

$ sdk install java 21.0.7-zulu

$ java -version
openjdk version "21.0.7" 2025-04-15 LTS
OpenJDK Runtime Environment Zulu21.42+19-CA (build 21.0.7+6-LTS)
OpenJDK 64-Bit Server VM Zulu21.42+19-CA (build 21.0.7+6-LTS, mixed mode, sharing)

$ java HelloWorld.java
An exception has occurred in the compiler ((version info not available)). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
java.lang.NoClassDefFoundError: com/sun/tools/javac/jvm/ClassReader$AttributeReader
    at jdk.compiler/com.sun.tools.javac.jvm.ClassReader.initAttributeReaders(ClassReader.java:841)
    ...

Fixed with Latest OpenJDK 21 and 25

With the latest builds of Zulu 21 (based on OpenJDK 21.0.8, released on July 15, 2025) and Zulu 25 (based on OpenJDK 25.0.0, released on September 16, 2025), the problem is solved!

$ sdk install java 21.0.8-zulu

$ java -version
openjdk version "21.0.8" 2025-07-15 LTS
OpenJDK Runtime Environment Zulu21.44+17-CA (build 21.0.8+9-LTS)
OpenJDK 64-Bit Server VM Zulu21.44+17-CA (build 21.0.8+9-LTS, mixed mode, sharing)

$ java HelloWorld.java
Hello, World!

$ sdk install java 25-zulu

$ java -version
openjdk version "25" 2025-09-16 LTS
OpenJDK Runtime Environment Zulu25.28+85-CA (build 25+36-LTS)
OpenJDK 64-Bit Server VM Zulu25.28+85-CA (build 25+36-LTS, mixed mode, sharing)

$ java HelloWorld.java
Hello, World!

Conclusion

Switching to the latest version of an OpenJDK build not only brings you security and performance improvements. It can also solve other problems, for instance, this one which is related to the hardware running your application. Thanks to the new Azul Zulu releases, you can now use the latest versions of OpenJDK/Java on your Raspberry Pi Zero 2!

The post Java 21+ on Raspberry Pi Zero 2 is Back In Business appeared first on foojay.