nordisk/znippy-zoomies

ljar — crate card

Reverse-engineered (from source — verify, don't trust the name)

• One-line pitch: A pure-Rust parallel JAR (ZIP-format) decompressor that scans the Central Directory and DEFLATE-decodes entries across cores.
• Does: Parses the ZIP Central Directory at the file tail into Vec<EntryLocation>, then dispatches each file entry to a rayon worker for independent DEFLATE decode, reassembling in Central-Directory order. In-memory slices < 10 MB decode in one parallel pass; larger/streaming inputs (Read + Seek) parse via tail-seek and decode in parallel batches of 64 without loading the whole file. Public API: JarEntry/JarError, StreamingJarRead, thread_pool(). Modules: batch, central_dir, chunk, deflate_scan, entry, parallel, reader.
• Key deps: rayon (dedicated pool, LJAR_THREADS override), intra-workspace linflate (re-exported as ljar::inflate — the DEFLATE core). Optional: flate2 zlib-ng (zlib-ng feature), zip+miniz_oxide (gen feature, for fixture-generating bench bins).
• Shape: lib + bins ljar (830) and gated bench/gen bins (bench_inflate_cmp, bench_large, gen_large_zip, need gen); ~3k LoC. doctest = false. Benches inflate_bench, chunk_into.
• Observed role in the workspace: Standalone parallel JAR decoder; sibling of lzip-parallel (near-identical architecture, JAR vs generic ZIP framing) and shares linflate. No in-workspace dependents observed (osm-katana pulls lgz/lbzip2/zstd, not ljar).

Fill in (one line each — only the human knows these)

• Primary consumer(s):
• Why it exists (vs the obvious alternative):
• Hard constraint (airgap / no-C-deps / no-FFI / pure-Rust / etc.):
• Release cadence & independence (rides a parent? own repo someday?):
• Status (production / prototype / experimental / stubbed):
• Must-NOT-change invariant:
• Biggest known gap or TODO:
• Anything a newcomer would get wrong about it: