Bytebox compiles Java to WebAssembly for Cloudflare Workers on a single blocking thread

The interesting engineering is in the build. Run `./gradlew buildWorker` and the plugin drives TeaVM over your bytecode, then writes a `wrangler.jsonc`, the WebAssembly module and an entrypoint; `./gradlew workerDeploy` hands the result to wrangler against your logged-in account ^[10]. No JVM appears in that output set ^[18]. The JDK is a build-time dependency, and what sits on the edge is a Wasm module with scaffolding around it. Configuration is a `handlerClass` pointing at your `Worker` implementation plus a `wrangler` block carrying the name and compatibility date ^[9].

The polyfill layer is good work. bytebox and TeaVM supply runtime capabilities for most of the standard library, and the Gradle plugin rewrites class files, including those inside dependencies, when they route to a system class that requires a polyfill ^[14]. `java.time`, `java.net`, `java.io` and `java.util.regex` are written as you would write them anywhere ^[14]. A jar you do not control gets patched on the way through, so a dependency gets ported, not rewritten. Substitution has a hard edge: the rewriter can replace an implementation, but it needs a thread that the host actually has.

That edge sets the shape of the code. The README's HTTP example calls `HttpClient.send` and waits on the response ^[15], because the host presents a single synchronous state in which every operation blocks ^[3] and the concurrency APIs are absent from the compile classpath ^[4]. Handlers implement `Worker.fetch(Request, Env, ExecutionCtx)` and return a `Response` ^[8]. Dynamic class loading is also listed out of scope ^[5], so anything in your stack that loads or generates bytecode at runtime has no route through this toolchain.

Bindings are declared in Gradle rather than hand-edited JSON, and the post says every Workers binding is supported: `kv()`, a named `kv("SESSIONS")` with an explicit remote id, `d1()`, `r2()`, and `durableObject("Counter")` producing `DO_COUNTER` ^[11]. There is a positional form as well, where `bindings(KV, D1, D1, KV)` yields `KV`, `DB`, `DB_2` and `KV_2` ^[12]. A `bindingsReport` task exists for when you want to find out which of those names you actually got ^[12]. JSON is annotation-driven: `@JsonType` on a record, `request.json(Order.class)` in, `Bytebox.json(order, Order.class)` out ^[13]. There is also a `Serial.encode` and `Serial.decode` pair for byte arrays ^[13].

In my context this is a reasonable trade for request-shaped services: parse the request, read KV or query D1, serialise, return. The first gate on any candidate service is whether its entire dependency closure compiles, because one reference to a threading API anywhere inside it turns into a build failure at compile time ^[4]. Anything holding a thread pool open in its startup sequence stays on a JVM host. Documentation for both the Java and TypeScript APIs is published, so the out-of-scope list can be read before you spend a sprint finding it empirically ^[7]. The constraint belongs to the Workers runtime, not TeaVM ^[3]. Polyfilling stops at that boundary.