The Problem · Too many translation layers
A typical Java enterprise web application is written in Java, SQL, JSON and JavaScript (or TypeScript), and the same data model is usually described three times along the way, i.e. once as a table, once as a class and once as a TypeScript interface. Your developers have to keep all of that in their heads at the same time, and so does an AI coding agent, and in my experience this is where most of the cost, most of the bugs and most of the security problems come from.
The Cost
Every time data crosses from one language into another, somebody has to write and maintain the code that does the crossing, and nobody can check that code automatically. For a human developer this is slow and annoying. For an AI coding agent it is generally worse, because it has to hold four different languages in its context at the same time, and sooner or later it starts guessing.
Your domain model is written in Java, but it is stored in relational tables, so you need SQL or JPA/Hibernate to translate between the two. That means you maintain two descriptions of the same idea (the class and the table) and keep them in step by hand.
eliminated by ZeroZ DB
The Java object is converted into JSON text, sent over HTTP, and then parsed back into a JavaScript or TypeScript object in the browser. Nothing checks that the two ends still agree, so if a field is renamed on the server you usually find out from a user.
eliminated by ZeroZ Stack
The browser DOM can only be changed from JavaScript or TypeScript, so even a pure Java team ends up with a second language, a second build tool chain and a second set of libraries, just for the screen.
eliminated by ZeroZ Stack
An AI coding agent working on such a feature has to reason about SQL, Java, JSON and TypeScript at once, and in practice that is where it starts inventing endpoints that do not exist, breaking the contracts between the layers and opening security holes.
So basically every translation layer stops the compiler and the IDE from helping you, makes refactoring risky, and forces you to maintain three different models of the exact same data.
The Solution
There is no ORM, no JSON and no JavaScript in a ZeroZ4J application, i.e. the translation layers are not made faster or thinner, they are simply not there any more. One Java object goes from the button click in the browser to the bytes on disk, and at no point is it re-encoded, copied or mapped into something else.
The server method receives exactly the object the client sent, so there is no controller, no deserialisation step and no mapping code to write. You can then store it or broadcast it to other clients as plain Java, which is usually two or three lines.
@ApplicationScoped public class ChatServiceImpl implements ChatService { @Inject ZeroZDbNode db; @Override public void sendMessage(ChatMessage msg) { // the exact object sent from the client db.localDb().write(ctx -> { root.getMessages().add(msg); ctx.store(root.getMessages()); }); } }
Because the whole stack is one language, an AI coding agent can usually generate a complete feature end to end and get it right the first time, and a human developer can rename a field from the database to the button click with one refactoring command in the IDE.
The family
ZeroZ4J consists of two independent projects, and both of them are built on the same conviction, namely that a Java object should not have to be translated into something else in order to be sent, stored or shown. You can use both together, or just the one you need (if you only want to try one, ZeroZ DB is the easier one to drop into an existing application).
ZeroZ Stack lets you write the whole application in Java, from the button click to the CDI bean. The browser runs compiled Java as WebAssembly, the wire carries packed binary frames over a persistent WebSocket, and the server is ordinary Jakarta EE. There is no JavaScript, no JSON, no REST controller and no DTO, so the object the client constructs is exactly the object the server method receives.
Eliminates: the network mismatch, the UI mismatch
With ZeroZ DB your Java objects are the database. It is a pure Java engine that adds what a real database has to have, i.e. serialised atomic transactions, crash durability, concurrent readers, maintained indexes and ownership safety across JVMs, without you ever leaving plain Java objects. There is no SQL, no ORM, no query language and no schema to keep in step with your classes.
Eliminates: the database mismatch
Both projects are Apache 2.0 and both are on Maven Central, and they take the same position, which is that the translation layers are the actual problem, and the right fix is to remove them rather than to make them faster.