DEV Community: Devansh Kant Kashyap

We Wrote a JSON Parser from Scratch in 72 Hours to Prove We Still Could

Devansh Kant Kashyap — Wed, 09 Sep 2026 14:44:39 +0000

Somewhere around hour thirty of ZeroDepsHack 2026, we were staring at a
parseUnicodeEscape method, arguing about whether a lone high surrogate
followed by a regular character should throw at parse time or survive until
serialization. The answer, per RFC 8259, was unambiguous — reject it — but the
fact that we were even having the conversation said something about how much
JSON parsing we'd been outsourcing to Jackson for years without thinking.

That was the question the hackathon was built around. Not "are dependencies
bad?" — they obviously aren't. But the supply chain keeps catching fire:
left-pad breaking half the JS ecosystem over 11 lines in 2016, the chalk
maintainer getting phished in 2025, npm's Shai-Hulud worm self-replicating
through hundreds of packages, AI coding tools hallucinating package names that
attackers pre-register. Jackson and Gson aren't the problem. The question is
whether we still understand what's inside the box we'd normally just import.
We decided to find out by building JValue — a zero-third-party-dependency
JSON toolkit for Java 25 — during the Aug 28–31 build window, for Track B:
Parsers & Data Formats.

What We Reimplemented

JValue shipped as a hand-written recursive-descent JSON parser, serializer,
RFC 6901 JSON Pointer implementation, file convenience API, and CLI — 14
production source files, roughly 3000 lines of Java, all compiled with javac
and depending on nothing beyond java.base. No Maven. No Gradle. No runtime
dependency jar anywhere. We verified this at submission with jdeps, which
confirmed every production class depended only on java.base.

The public API surface we ended up with fit in a few lines:

JsonValue doc = Json.parse(jsonString);
String compact = Json.stringify(doc);
String pretty  = Json.stringifyPretty(doc);
String name    = Json.pointer(doc, "/users/0/name").asString();

Json.writePrettyFile(doc, Path.of("out.json"));
JsonValue back = Json.read(Path.of("out.json"));

The value model was a sealed interface hierarchy — JsonObject, JsonArray,
JsonString, JsonNumber, JsonBoolean, JsonNull — which meant the
compiler enforced exhaustive handling in switch expressions. That's something
Jackson's JsonNode still doesn't give you: if you forget a case, javac
tells you at compile time rather than letting it slip through to production.

We also built a CLI with 15 commands — validate, pretty, compact, get
(JSON Pointer lookup), inspect, roundtrip, build, array, numinfo,
and more — all routed through a single switch expression on args[0] in
JValueCli.java. No picocli. No Commons CLI. Just String[] args.

What the Standard Library Made Painful

Java's standard library is enormous and capable, but it was specifically missing
two things that mattered for this project: a JSON implementation and a test
framework.

No JSON anything. Python ships json. Go ships encoding/json. Ruby ships
json. Java ships... javax.json in Jakarta EE, which isn't in java.base
and requires a runtime provider dependency. The entire reason Jackson exists is
this gap. Building JValue meant writing a complete RFC 8259 parser, a
serializer, string escape handling, Unicode processing, and number grammar
enforcement from nothing but java.lang.String, java.lang.Character, and
java.util.LinkedHashMap.

No test framework. The JDK doesn't ship JUnit — it's a third-party
dependency, which this hackathon didn't allow. We wrote a test harness from
scratch: TestRunner.runTest(String, Runnable) wrapped each test, caught
AssertionError for failures and Exception for errors, accumulated counts,
and exited nonzero on failure. We wrote assertEquals, assertTrue,
assertThrows, and the rest by hand. It worked. It was not fun. No
parameterized test sugar, no IDE integration, no annotation discovery. You
called your test methods from main() and you liked it.

One specific annoyance: fetching external test corpora. We wanted to run
JSONTestSuite's 318 conformance files, but git submodule and curl were
external tools. We ended up writing FetchCorpus.java — a small JDK-only
utility that used java.net.http.HttpClient to download the ZIP archive from
GitHub, java.util.zip.ZipInputStream to extract it, and java.nio.file.Files
to write the files out. It included zip-slip protection. It exited cleanly if
offline so the build didn't break. It was the kind of thing you'd never write if
curl | tar xz were on the table, but it worked, and it was zero-deps.

The Package We Made Look Unnecessary

Jackson (com.fasterxml.jackson). Specifically, the tree-model workflow:
ObjectMapper.readTree() → traverse JsonNode → generate output. JValue
replaced that vertical slice completely. Parse JSON text into a typed tree,
navigate it, serialize it back — all without Jackson, Gson, or any third-party
jar on the classpath.

We weren't claiming Jackson is unnecessary in general. Jackson's streaming API,
its POJO binding, its annotation system, its format modules — none of that was
in JValue, and we didn't pretend it was. What we demonstrated was that the core
tree-parse-serialize workflow — the reason most projects add Jackson in the
first place — was buildable from the JDK in a weekend if you were willing to
write it by hand.

Our STDLIB.md tracked 12 specific substitutions with honest tradeoff
documentation for each: Jackson's ObjectMapper → our recursive-descent parser.
Jackson's JsonGenerator → our hand-written serializer. Guava's ImmutableMap
→ Collections.unmodifiableMap() wrapping LinkedHashMap. JUnit 5 → our test
harness. AssertJ → hand-written assertions. ICU4J → java.lang.Character
surrogate methods. picocli → String[] args switch expressions. Apache Commons
IO → java.nio.file.Files. Each entry documented what we lost, not just what
we gained.

The Edge Case That Ate Real Time

Unicode surrogate pairs.

The JSON spec allows any Unicode code point in a string, but characters outside
the Basic Multilingual Plane (above U+FFFF — emoji, musical symbols, historic
scripts) must be encoded as a pair of \uXXXX escapes: a high surrogate
(U+D800–U+DBFF) followed immediately by a low surrogate (U+DC00–U+DFFF). The
parser had to match them, reject lone surrogates in either direction, and
assemble the actual code point via Character.toCodePoint().

Here's the core of parseUnicodeEscape from JsonParser.java as it shipped:

private char[] parseUnicodeEscape() {
    int codeUnit = parseHex4();

    if (Character.isHighSurrogate((char) codeUnit)) {
        if (source.isAtEnd() || source.peek() != '\\') {
            throw source.error("High surrogate U+"
                + String.format("%04X", codeUnit)
                + " must be followed by a low surrogate");
        }
        source.advance(); // consume '\'
        if (source.isAtEnd() || source.peek() != 'u') {
            throw source.error("High surrogate U+"
                + String.format("%04X", codeUnit)
                + " must be followed by \\uXXXX low surrogate");
        }
        source.advance(); // consume 'u'
        int lowUnit = parseHex4();
        if (!Character.isLowSurrogate((char) lowUnit)) {
            throw source.error("Expected low surrogate but found U+"
                + String.format("%04X", lowUnit));
        }
        int codePoint = Character.toCodePoint(
            (char) codeUnit, (char) lowUnit);
        return Character.toChars(codePoint);
    }

    if (Character.isLowSurrogate((char) codeUnit)) {
        throw source.error("Unexpected low surrogate U+"
            + String.format("%04X", codeUnit)
            + " without preceding high surrogate");
    }

    return new char[]{(char) codeUnit};
}

The same strictness showed up on the serialization side — the serializer
validated that Java strings didn't contain lone surrogates before emitting them,
and rejected them with IllegalArgumentException. Both directions had to agree,
or round-trip tests broke.

We also burned real time on the number grammar. RFC 8259's number production
looks trivial — [ minus ] int [ frac ] [ exp ] — but the details compounded:
leading zeros were illegal (except bare 0), a trailing decimal point was
invalid, +1 was invalid, hex notation was invalid, NaN and Infinity were
invalid. We preserved the raw lexeme through parsing so that -0, 1.0, and
1e0 all round-tripped exactly as written — a property Jackson's JsonNode
doesn't guarantee.

What We Shipped

By the Aug 31 code freeze:

186 hand-written tests, all passing. Zero failures, zero errors.
305 JSONTestSuite conformance cases passing, 0 failed, 13 skipped (the skipped cases were byte-level encoding tests that didn't apply to our String-based parser).
15 CLI commands — routed through a single switch expression on args[0] in JValueCli.java.
Zero third-party production dependencies, confirmed by jdeps — every production class depended only on java.base.

The CLI was the part that made the project feel like a real tool rather than just
a library:

$ ./jv.sh validate data.json
  ✔  Valid JSON
  Root type : object
  Keys      : 3

$ ./jv.sh get data.json /users/0/name
  Pointer : /users/0/name
  Type    : string
  Value   :
"Ada Lovelace"

What We Learned

Building a JSON parser from scratch turned out to be deeply educational and
moderately miserable. We learned more about RFC 8259 in that weekend than we had
in a decade of using Jackson. We also discovered that the spec was full of small
traps — surrogate pairs, the exact set of legal whitespace characters, whether a
leading BOM counts as valid input (we rejected it), whether trailing commas are
allowed (they are not) — that libraries handle invisibly.

If we're honest, the actual hard part of this weekend wasn't writing Unicode-handling code — most of that came together faster than either of us expected once the architecture was in place. The hard part was deciding how much to trust it. It's easy to generate a recursive-descent parser quickly now; it's much harder to know, with a submission deadline closing in, whether the thing you generated actually does what it claims. So most of our real effort in the last stretch went into verification rather than writing: running the parser against files we hadn't tested before and reading the output ourselves instead of trusting a green checkmark, deliberately breaking things to see if the errors pointed where they should, checking that a file written on one path and read back on another actually agreed. None of that shows up as a diff in the repo. If we had to hand one piece of advice to the next team building this way, it wouldn't be about surrogate pairs — it's that when an AI can generate the hard part in an afternoon, the bottleneck quietly moves to verifying it, and that's the part you can't delegate.

We disclosed every tradeoff. Our STDLIB.md didn't just list substitutions; it
documented what we lost — no POJO binding, no streaming, no configurable
pretty-printing. Our README.md had a Limitations section. Overclaiming costs
more than it gains when judges are senior engineers who will read the source.

If we had the weekend back, there are things we'd explore — Reader/
InputStream parsing, streaming serialization, maybe JSON Patch. But the point
of the project was never to replace Jackson wholesale. It was to answer a
narrower question: for the core tree-parse-serialize workflow that most projects
actually use Jackson for, do we still know how to build that ourselves? By
submission, we had 186 passing tests, 305 conformance cases, and a jdeps
report that said java.base and nothing else. The answer was yes.

Built for ZeroDepsHack 2026 — Track B: Parsers & Data Formats. Organized by Hackathon Raptors.

raptors.dev

We ported JSBI to C++ — and the benchmark taught us more than the port did

Devansh Kant Kashyap — Tue, 11 Aug 2026 13:40:46 +0000

TL;DR: We ported GoogleChromeLabs/jsbi — a pure-JS arbitrary-precision integer library — to modern C++17, bridged back to Node via N-API, for Port Mortem 2026 (Track H). The port itself wasn't the hard part. Proving it behaved identically to the original — and being honest about the one place we couldn't prove that — was.

This is the story of a compile error that was secretly a correctness bug, a shared_ptr that lied about owning memory, and a benchmark that changed its mind three times in a row, and what we did when it wouldn't sit still.

Why JSBI → C++, of all pairs

JSBI isn't really a JavaScript library. It's V8's internal MutableBigInt — written in C++ — manually downgraded to 30-bit digits so its arithmetic could survive inside JavaScript's 2^53 safe-integer ceiling without silently losing precision. Every multiply in the original source carries a 15-bit split trick that exists for exactly one reason: JS numbers can't safely hold the product of two 32-bit values.

So porting it back to C++ isn't a random language swap for Track H credit. It's undoing a constraint. In C++, a uint64_t accumulator holds that same product natively — no split needed. We weren't rewriting an algorithm. We were giving one back its native width.

Original: V8 C++ MutableBigInt → downgraded to 30-bit digits → shipped as JS
This port: JS jsbi → C++17, native 64-bit accumulators → the loop closes

The verification pipeline

Two of us, 72 hours. The port had to run the original test suite unmodified — not a translated copy, the literal upstream files, pinned via git submodule at the kickoff commit hash, so nobody has to take our word for what "unmodified" means.

tests/original-upstream/*.mjs   (pinned submodule, byte-identical to upstream)
              │  import JSBI from '../dist/jsbi.mjs'
              ▼
tests/dist/jsbi.mjs             (thin JS bridge — API shape only, zero math logic)
              │  require(native addon)
              ▼
src/addon.cpp                   (N-API boundary — ownership + exception mapping)
              │
              ▼
src/jsbi.cpp / jsbi.hpp         (the actual math — zero Node/V8 headers, by design)

That last line matters more than it looks: the core engine has zero includes from Node or V8. You can grep -L napi.h src/*.cpp and confirm it yourself. If this project ever needed to compile standalone — WASM, embedded, whatever — the math layer doesn't care that N-API exists.

On top of the pinned test suite, we ran a three-way differential fuzzer every session: native V8 BigInt, the real upstream jsbi npm package, and our port, on identical inputs, for 60+ seconds at a time. Three-way, not two — because a two-way comparison against native BigInt alone can't tell you whether a divergence is in your math or in your bridge wrapper. Three-way can.

209,401 iterations, zero divergences, on the final clean run.

What broke — four bugs, in increasing order of "wait, that's not a style nitpick"

1. The compile error that was hiding a correctness question

r.digits.empty() ? (r.digits.push_back(1), void()) : (r.digits[0] |= 1);

This was in our division algorithm. It looks like a harmless one-liner. It's actually ill-formed C++ — the ternary operator requires both branches to share a common type, and void is only compatible with another void, or with a throw-expression. r.digits[0] |= 1 has type uint32_t&. Neither branch qualifies. GCC and Clang under -std=c++17 reject this outright. It happened to build on our first Windows/MSVC pass, which is a genuinely dangerous kind of luck — it meant our first "it compiles" signal was compiler-specific, not portable. We didn't find this by reading docs. We found it by trying to build on a second toolchain and watching it fail.

2. A `shared_ptr` that owned nothing

return std::shared_ptr<jsbi::JSBI_CPP>(std::shared_ptr<jsbi::JSBI_CPP>{}, raw);

This is the aliasing constructor, called with an empty control block. It type-checks. It has -> and .get(). Its use_count() is zero. It contributes nothing to keeping the object alive — it's a raw pointer wearing a shared_ptr costume, sitting in a codebase whose entire pitch for the Zero-Unsafe bonus was "we don't do that." The fix was smaller than the bug: return an honest, documented, non-owning raw pointer instead, and let the real shared_ptr — the one captured in the N-API finalizer closure — do the actual owning. Faking safety is worse than admitting you're borrowing.

3. The spec quirk nobody wrote a test for, until the fuzzer got wide enough

if (b.is_negative) throw std::invalid_argument("Cannot shift by negative amount");

Reasonable-looking guard. Spec-wrong. 5n << -1n doesn't throw in real BigInt — it redirects to 5n >> 1n. Negative shift counts aren't an error, they're a direction flip. This bug was invisible to our own fuzz harness for a while, because our shift-amount generator only ever produced values 0 to 64. The bug wasn't in the math. It was in the range of inputs we were brave enough to generate. Widening the generator to -64..64 is what actually caught it — not code review, not the original test suite, just deciding to stop being polite to our own implementation.

4. The sign character nobody thought to negate

BigInt("-0x1") throws — non-decimal radixes don't accept a sign, and our code correctly rejected the - case. BigInt("+0x1") should also throw, for the same reason. Ours didn't. We were only tracking is_negative, and + doesn't set that flag — so a + before a hex prefix sailed straight through unguarded. Caught during a manual code-review pass, not fuzzing, because our fuzz string generator never happened to emit a leading + before a 0x. A reminder that fuzzing finds what your generator can imagine, and code review finds what it can't.

The benchmark that wouldn't agree with itself

Here's the part I actually want other teams to read.

We built an honest benchmark harness — real hrtime.bigint() measurements, forced GC between blocks, identical operand pairs fed to both implementations, three operand sizes so we couldn't hide behind a single flattering number. First run, large operands:

Operation	Original JS	Our Port	Verdict
`add`	3.78ms p99	1.60ms p99	Port wins, clearly
`divide`	1.60ms p99	3.63ms p99	Port loses, clearly

Clean story. Port wins at addition, loses at division — makes sense, our division is a bit-serial restoring-division algorithm, upstream's is presumably limb-serial. Write it up, move on.

Except we ran it again.

Operation	Run 1	Run 2	Run 3
`add` (port vs original)	1.75× faster	1.09× faster	0.95× (slightly slower)
`divide` (port vs original)	0.69×	1.08×	0.86×

Three runs. Same machine. Same code. No consistent winner on any operation. The "our division algorithm is measurably worse" story I was ready to write didn't survive a second data point.

We had two options. Report the run that told the best story. Or report what actually happened.

We reported the range. All three runs, in the README, with the honest conclusion: measurement noise on a general-purpose Windows machine dominates whatever true performance difference exists, we don't have a reliable claim to make, and here's exactly why (shared long-lived process across every block, non-isolated host, cumulative RSS climbing past 1.2GB by the last measurement). We even named the fix we didn't have time to do — isolated process per block, Linux CI runner, median-of-ten instead of a point estimate — as explicit future work instead of a silent gap.

That's not the exciting version. It's the true one. And per this hackathon's own scoring language — hiding a regression scores worse than disclosing it — inconclusive-and-honest beats confident-and-wrong every time a judge actually checks your numbers instead of just reading your headline.

The decision I'd take back

We spent real hours getting the N-API bridge to a place where the literal, unmodified, pinned upstream test files could require() our compiled binary directly — zero-touch, not a translated copy. It's the more defensible architecture, and I'd make the same call again on the merits. But it cost us a full evening fighting Windows toolchain issues that had nothing to do with C++: node-gyp not recognizing a newer Visual Studio release, a Build Tools install silently missing the Windows SDK component, the kind of error that eats a clock without teaching you anything about your actual port.

If I ran this again, I'd stand up a Linux/WSL2 build path in the first hour, not discover I needed one during a compile failure. The bridge architecture was worth it. The hours lost to a toolchain neither of us had properly checked ahead of time were not — that's just tax, and I'd pay it earlier and smaller if I could.

Final scorecard

246/246 assertions passing against the pinned, unmodified upstream test suite (submodule-hashed at kickoff, not a copy)
209,401 three-way differential fuzz iterations, zero divergences
33+ entries in our decision log — including, deliberately, the ones marked Superseded and Known Limitation, because a log that only records what worked isn't a log, it's a highlight reel
Zero raw new/delete, zero fake ownership (after we caught the one that was faking it), zero Node/V8 dependency in the math core
One benchmark result we can't confidently claim — and said so, in writing, instead of picking the run that looked good

Reproduce it yourself

Repository: https://github.com/codewisp-ai/Coderesurrection-2026
Demo (original test suite passing live against the port): https://youtu.be/UKKCHzXfF5Y
Full decision log: DECISIONS.md in the repo — read the Superseded entries first, they're more honest than the accepted ones

Closing thought

Anyone with an AI coding agent can produce C++ that compiles. Ours didn't, the first time — and the compiler catching that was luckier than it should have been, since a more permissive toolchain let it through initially.

What we actually spent 72 hours on wasn't writing arithmetic. It was building enough ways to catch ourselves being wrong — a pinned test suite we couldn't quietly edit, a three-way fuzzer that could tell our math bugs from our bridge bugs, a benchmark methodology honest enough to report its own noise instead of its best headline.

The port is the artifact. The willingness to publish the run that didn't flatter us is the actual submission.

PortMortem2026 #HackathonRaptors #Cpp #JavaScript #SystemsProgramming #Testing #NAPI