Ecosystem: Why "No Package Registry" Misses the Point
The third standard objection to SuperJ — after "no threads" and "no memory safety" — is "no ecosystem: other languages have package registries, SuperJ has one SDK." The framing assumes an ecosystem is a source-level thing, and at that layer it's true: you can't pull a package from another language's registry into a SuperJ project and get its compile-time macros, its async desugaring, its trait-based dispatch.
But SuperJ is an LLVM language, and that changes the math.
The linkable ecosystem is the compiled ecosystem
SuperJ's native keyword links C ABI symbols — that's how the SuperJ runtime library works today. Every other LLVM language (C, C++, Zig, Swift, and the rest) can export extern "C" functions, which are just LLVM IR functions with the C calling convention. SuperJ links them the same way it links its own runtime. You get the compiled, ABI-stable portion of every LLVM language's ecosystem for free:
- Crypto — BoringSSL, libsodium, libsecp256k1 (already linked by SuperJ's own SDK native layer).
- Compression — zstd, lz4, zlib, brotli.
- Numerical kernels — BLAS/LAPACK, simde, OpenMP runtime.
- Parsers — the compiled core of any parser library (the macros and derives don't cross language boundaries — they don't cross any language boundary, not even to C).
- System bindings — anything with a C header is already linkable.
This is the part of an ecosystem that actually matters for linking. The part you don't get — derive-style serialization macros, async desugaring, trait-based routing frameworks — is the ergonomic layer, which lives at the source language level and doesn't cross language boundaries in any direction (you can't use another language's macros from C either). That layer is convenience, not capability: a derive macro expands to functions over a compiled core, and it is the core you can link from SuperJ and invoke through a thin native wrapper.
The asymmetry that matters
Every source-level ecosystem can link C, but none can export its ergonomic layer to a foreign host — macros and derives are compile-time expansions that require their own compiler, so every package registry is monolingual at the ergonomic layer. SuperJ is multilingual at the link layer: anything that compiles to LLVM IR with a C ABI is a native declaration away. The "ecosystem advantage" reverses once you stop conflating the source-ergonomic layer with the linkable-capability layer.
What SuperJ's own SDK already covers
The SuperJ SDK isn't a token gesture — it covers the cases where the ergonomic layer would otherwise matter:
- Collections — primitive-specialized (
IntArrayList,Int2IntMap,Obj2ObjMap<K,V>,IntSet, …) avoiding the boxing a generic Java collection would impose. - JSON — a hand-written incremental parser, no derive macros needed.
- HTTP/1.1 — an incremental server with TLS 1.3.
- SEDA — the event-driven framework this manual is built around.
- Crypto — SHA256 (ARM NEON), Secp256k1 for blockchain.
- Math, Integer, Long, Short — full
java.lang.Mathequivalent.
The cases where you'd reach for another language's package are mostly the cases where the compiled core is linkable anyway: you want zstd, you link zstd. You want BLAS, you link BLAS. You want a specific parser, you link its compiled core. The SuperJ SDK covers the Java-ergonomic gap (collections, JSON, HTTP); the LLVM link layer covers the systems gap (everything else).
The honest remainder
What you genuinely can't get: a library that requires its source language's compile-time features to function at all — a package whose entire API surface is generated by compile-time macros, with no extern "C" fallback. Those exist but are rare; most real capability crypto, compression, numerical kernels, parsers has a C-ABI core underneath the ergonomic sugar. The ergonomic sugar is what you write yourself in SuperJ, and because SuperJ is Java-shaped, that sugar is cheap: a native declaration and a thin wrapper method. That's the cost of being a small ecosystem, and the LLVM link layer is what keeps it small rather than crippling.