Xberg 1.0 released: document extraction for a world of tooling | bytecode.news

ByteCode.News<br>Search posts🔍<br>RSS

content-extractionjavarusttikatooling

Xberg 1.0 has been released. Xberg is a document extraction engine, describing itself as a "document intelligence framework." It's written in Rust, with fifteen generated language bindings, and a very descriptive data model that provides a lot of flexibility. There are other content extraction frameworks; for Java, it'd be compared to Tika, and against Unstructured for Python. I didn't run a comparison against Unstructured, but I do have some comparison points for Tika.

Measuring the Overlap

Xberg is a rebrand of the Kreuzberg project; Kreuzberg still exists, but is expected to be supported (for critical fixes only) through the end of 2026, with future development moving to "Xberg." The rebrand changes project coordinates throughout (to io.xberg:xberg), so old references to Kreuzberg aren't going to magically get Xberg instead; it is a migration, and not a promotion, although migration should be pretty easy once you've changed the coordinates of the structures.

Xberg is written in Rust, with bindings for Java, Python, Ruby, Go, PHP, Elixir, C#, R, C, TypeScript across several runtimes, and more. Those bindings are not fifteen hand-maintained ports: they are generated from the Rust core by an in-house binding generator. The engine covers more than ninety document formats, does code intelligence across three hundred-odd programming languages through tree-sitter, and runs OCR through pluggable backends, with Tesseract compiled in natively and PaddleOCR available through ONNX Runtime. You can consume all of it as a library, a CLI, a REST service, or an MCP server.

The output model is ambitious. Tika-style extraction gives you text and metadata; Xberg's result model carries elements, tables, images, chunking with pluggable tokenizers, and structured extraction, because the project is aimed at pipelines that want structure, not strings.

The Apache Tika project, probably the gold standard for such extraction for Java, predates the entire idea of a machine as the reader; it was built when extraction fed search indexes and human eyes, and its output shape fits that model well. Xberg assumes an agent might be the caller. The MCP server is a first-class surface, chunking is token-budget-aware down to letting you register the exact tokenizer your embedder uses, and structured extraction exists so whatever sits downstream receives shape rather than a wall of text. None of it is mandatory, and I actually used the plain text resultset for my tests: I ignored all of this machinery at no cost1. Xberg was built for now: a world in which the reader of an extraction result might not be human.

The view from one window

I replaced Tika in a Java application with Xberg, and retained A/B comparison data. I did not compare any other language bindings; my assumption, given how the bindings are generated, is that there will be a rough equivalence for other languages as appropriate for their design, but I can make no assertions about that for sure.

The application itself ran over a disparate corpus: images, documents in various formats like Word, PDF, even WordPerfect, and images with text, in various formats as well. It was a fairly wide scannable surface by design, intending to represent "general ingestion." This gave me compatibility information, efficiency comparison, and typical format conversion information.

On the JVM, Xberg requires Java 25 for the Foreign Function and Memory API. Packaged launchers require the native access flags, and java.awt.headless=true is required for sane server behavior on macOS2. The macOS ARM64 artifact carries its own Tesseract; it does not shell out to a system executable the way Tika does. It wants an explicitly located Tessdata directory and a writable cache directory, and it wants that cache directory even when its caches are disabled3. Tika can use Tesseract, but it's optional; Xberg embeds Tesseract but can use other OCR platforms if desired. There's not really a good answer to whether one approach is better than the other; it's just a design decision, where Xberg assumes that OCR shall be available whereas Tika assumes that it might be available.

It's possible that bugs like the cache reference and other such things are localized to the actual language binding, so Rust-native consumers of Xberg might not see the same problems, and the same might go for Python or any others. This is common for polyglot projects; specific behaviors can be difficult to determine without spanning many use cases.

Tika and Xberg don't quite compete

As I mentioned, my comparison was Apache Tika, but the comparison is... limited. Tika and Xberg are not competing projects. They overlap in very few regions, with a focus on getting text out of documents.

Tika is an aggregate project. It leverages the Java ecosystem, wiring PDFBox and POI and dozens of other...