OxiArc 0.2.3 Released — Async ZIP and DEFLATE Streaming Arrive, Plus a Dedicated GIF LZW Codec

The COOLJAPAN compression layer just went async.

Today we released OxiArc 0.2.3 — pure Rust archive and compression, now with async ZIP and async DEFLATE/GZip streaming for non-blocking pipelines, plus a dedicated GIF LZW codec.

No C. No Fortran. No zlib. No libzip. No libarchive. No 7-zip. No external shared libraries.
No FFI overhead. No build hell.
Just clean, memory-safe, blazing-fast archiving and compression that compiles to a single static binary (or WASM) and runs everywhere.

Why OxiArc 0.2.3 matters

Handling archives and compression has long meant leaning on heavy native libraries — zlib, libzip, libarchive, 7-zip — with all the baggage that brings:

• Complex build systems and dependency hell
• Security risks from large, aging C codebases
• Platform-specific binaries and vendor lock-in
• Difficulty in WASM, embedded, or no_std environments
• Inconsistent support for legacy formats like LZH and Shift_JIS (still widely used in Japan)

Modern services are async from end to end — and a compression step that blocks the runtime stalls everything behind it. 0.2.3 makes the hot formats non-blocking: ZIP, DEFLATE, and GZip now have async paths that drop straight into a Tokio or async-std pipeline, so compressing a large payload no longer parks a worker thread. And on the image side, GIF finally gets its own dedicated LZW codec.

Technical Deep Dive: Non-Blocking Codecs and a GIF Path

OxiArc keeps its layered shape — a core layer, codec crates, a container layer, and a CLI — and 0.2.3 lands new modules across the Codec and Container layers.

1. Core Layer (oxiarc-core) Shared Compressor/Decompressor traits, CRC-32/64/16 with slicing-by-8, and bitstream utilities — carried forward unchanged.

2. Codec Layer

   • oxiarc-deflate gains an async path: a new async_deflate module for non-blocking compress/decompress, plus a dedicated gzip module. Both are Tokio/async-std compatible, so DEFLATE and GZip streaming fit a non-blocking pipeline.
   • oxiarc-lzw adds a dedicated gif_lzw codec module and an bitstream_lsb module — GIF’s LSB-first bitstream is now first-class rather than a flag on the general LZW path.

3. Container Layer (oxiarc-archive) A new async_zip module brings non-blocking ZIP reading and writing — read entries or build archives without blocking the runtime.

4. CLI Layer (oxiarc-cli) The unified oxiarc binary, carried forward.

This release also sharpens the engines underneath: oxiarc-deflate’s LZ77 match-finding, deflate engine, and lib interface; oxiarc-lz4 dictionary and HC improvements; oxiarc-lzma encoder, model, and optimal-parsing refinements; oxiarc-zstd frame and streaming improvements; oxiarc-lzhuf LZSS improvements; oxiarc-bzip2 BWT improvements; and oxiarc-archive ZIP header reader and module-level cleanups.

Getting Started

0.2.3 is on crates.io. For async pipelines, pull in the crates you need and enable async I/O:

cargo add oxiarc-archive    # async ZIP via the async_zip module
cargo add oxiarc-deflate    # async DEFLATE + GZip

Async I/O is feature-gated — enable the async-io feature to light up async_zip and async_deflate for non-blocking work. The familiar synchronous API is unchanged:

use oxiarc_deflate::{deflate, inflate};
use oxiarc_archive::ZipReader;
use std::fs::File;

let compressed = deflate(b"Hello, World!", 6)?;   // level 0-9
let decompressed = inflate(&compressed)?;

let file = File::open("archive.zip")?;
let mut zip = ZipReader::new(file)?;
for entry in zip.entries() {
    println!("{}: {} bytes", entry.name, entry.size);
}

With async-io on, reach for the new async_zip and async_deflate modules to run those same operations without blocking. For GIF work, the new gif_lzw module handles GIF encoding and decoding directly.

What’s New in 0.2.3

• Async ZIP. A new async_zip module in oxiarc-archive brings non-blocking ZIP read/write.
• Async DEFLATE + a GZip module. oxiarc-deflate adds an async_deflate module for non-blocking compress/decompress, plus a dedicated gzip module — both Tokio/async-std compatible.
• A dedicated GIF LZW codec. oxiarc-lzw gains a gif_lzw module and an bitstream_lsb module, making GIF’s LSB-first bitstream first-class.
• Codec refinements across the board. Improvements to DEFLATE LZ77 match-finding and the deflate engine; LZ4 dictionary and HC handling; LZMA encoder/model/optimal-parsing; Zstd frame and streaming; LZSS in oxiarc-lzhuf; the bzip2 BWT; and the ZIP header reader.

Quality this release: zero Clippy warnings, zero rustdoc warnings, and a 100% test pass.

Tips

Getting the most out of the async paths and the new GIF codec:

• Enable async-io for Tokio services. With the feature on, async ZIP and async DEFLATE/GZip let you compress large payloads without parking a worker thread.
• Use gif_lzw for GIF, not the generic LZW path. It defaults to the GIF dialect and the LSB-first bitstream the standard requires — no flag juggling, no garbage output.
• Stream GZip through the new gzip module. For long-running or chunked output, GZip streaming beats buffering the whole payload in memory.
• Trade CPU for ratio with LZ4-HC. When bandwidth matters more than encode time, the high-compression LZ4 path squeezes harder for a modest CPU cost.
• Migrate flate2 callers to oxiarc-deflate. The sync deflate/inflate API is a drop-in shape, and you gain the async path for free — without pulling zlib into the build.

This is the foundation

OxiArc is the compression and archival backend other COOLJAPAN projects build on. It still depends on no sibling projects — just small, focused Rust crates — so siblings sit on top of it, not beside it.

Async ZIP and DEFLATE make OxiArc a clean fit for high-throughput ingestion in the COOLJAPAN data stack — SciRS2, NumRS2, and PandRS pipelines that pull and pack data without blocking the runtime — and for OxiMedia asset pipelines that stream large files end to end. It is the quiet data-packaging layer underneath the COOLJAPAN scientific and media stack.

Repository: https://github.com/cool-japan/oxiarc

Star the repo if you want high-performance archiving and compression without the traditional native toolchain headaches.

Pure Rust archiving and compression is here — fast, safe, and sovereign.

— KitaSan at COOLJAPAN OÜ March 11, 2026