Apache Tika 4.x: Markdown als Standardausgabe, Fork-Isolation und ein schlanker tika-app-Launcher

Was Tika 4.x gegenüber Tika 2.x verändert

Apache Tika ist ein in Java geschriebenes Toolkit der Apache Software Foundation, das Metadaten und Text aus über tausend Dateitypen erkennt und extrahiert. Die Repository-Beschreibung nennt PPT, XLS und PDF als Beispiele. Eine vollständige Formatliste führt die README nicht auf; die Formaterkennung passiert zur Laufzeit, nicht über eine Konfigurationsdatei.

Mit 4.0.0 verschiebt sich laut README die Ausgabe: Tika liefert standardmäßig Markdown statt Rohtext. Die im README gegebene Begründung ist praktisch, denn Markdown lässt sich mit Überschriften und Tabellenstruktur direkt in LLM- und RAG-Pipelines einspeisen. Wer dennoch Rohtext braucht, ruft `--text` auf und bekommt das alte Verhalten.

Der zweite Umbau betrifft die Fehlerklasse. Tika 4.x parst in eigenen Fork-Prozessen, die voneinander abgeschottet sind. Ein beschädigtes oder feindselig aufgebautes Dokument reißt dann den Fork mit, nicht den Dienst, der Tika eingebettet hat. Für einen Batch-Job über Tausende unbekannte Uploads ist das ein anderer Ausfallmodus als ein Parse-Fehler, der die ganze JVM beendet. Wie hoch der Startaufwand pro Fork ist und ob sich das bei vielen kleinen Dateien bemerkbar macht, steht in der README nicht.

Tika 2.x und die Unterstützung für Java 8 sind seit April 2025 am Ende ihrer Laufzeit. Die README verweist auf das Tika-Roadmap-Wiki für den Supportplan der einzelnen Linien. Wer auf 2.x sitzt, hat damit keinen gepatchten Pfad mehr und sollte den Sprung einplanen, statt ihn aufzuschieben.

VLM-Parser in Tika für Dokumente, die OCR nicht liest

Tika 4.x ergänzt Parser, die ein Vision-Language-Modell ansprechen, namentlich Claude, Gemini und OpenAI. Das im README genannte Einsatzgebiet sind Dokumente, an denen klassische OCR scheitert, etwa Handschrift oder schlecht erhaltene Scans.

Damit wandert eine externe Abhängigkeit in die Extraktionskette. Die README nennt keine Preise, keine Rate-Limits und kein Fallback-Verhalten für den Fall, dass der Modell-Endpunkt nicht erreichbar ist. Diese Lücke ist kein Randdetail: Eine Anfrage pro Seite an einen kostenpflichtigen Endpunkt verändert die Kostenstruktur eines Batch-Jobs, und ein Parser, der bei Netzwerkfehlern still auf eine leere Seite zurückfällt, produziert Ergebnisse, die man später schwer von echten Leerseiten unterscheidet. Beides muss man vor dem Aktivieren selbst prüfen, die README liefert dazu nichts.

Für den Containerbetrieb mit garantierter OCR liegen im Repository unter `.skills/` zwei agentfertige Skill-Dateien: `file-to-markdown` für das Parsen über tika-app oder tika-server und `file-to-markdown-docker` für die containerisierte Variante. Die README beschreibt beide als eigenständig, sie lassen sich also in ein beliebiges Skill-Verzeichnis kopieren und brauchen das Tika-Repository selbst nicht.

Der tika-app-Download und der NoClassDefFoundError

Wer Tika nur auf der Kommandozeile braucht, lädt laut README das Archiv `tika-app-<version>.zip` von tika.apache.org/download.html und entpackt es. Die README weist ausdrücklich darauf hin, dass das Archiv kein übergeordnetes Verzeichnis enthält. Wer es unachtsam in ein bestehendes Verzeichnis entpackt, verteilt dort seine Dateien, statt einen eigenen Ordner zu erhalten.

Wichtiger ist der Aufbau der JAR. Sie ist ein schlanker Launcher, der die Parser aus dem benachbarten `lib/`-Verzeichnis lädt. Startet man sie allein, bricht der Aufruf mit `NoClassDefFoundError` ab. Man muss also aus dem entpackten Verzeichnis heraus arbeiten und darf die JAR nicht herauskopieren.

Die drei dokumentierten Aufrufe:

`java -jar tika-app-<version>.jar document.pdf` erzeugt Markdown, `--text` erzeugt Rohtext, `-J` erzeugt strukturiertes JSON mit Metadaten und Inhalt sowohl für das Dokument selbst als auch für eingebettete Objekte. Für die rekursive Verarbeitung nennt die README zusätzlich den Endpunkt `/rmeta` des tika-server. Genau diese Rekursion ist der Punkt, an dem ein unbedachter Upload teuer wird: Ein Archiv, das seinerseits Dokumente enthält, vervielfacht die Ausgabe.

Der Java-Einstieg ist dagegen ein Zweizeiler: `new Tika().parseToString(new File("document.pdf"))`. Welche Parser dabei geladen werden, hängt von der eingebundenen Modulmenge ab, nicht von diesem Aufruf.

tika-bom und tika-parsers-standard-package als Abhängigkeit

Tika ist kein einzelnes Artefakt, sondern eine Modulfamilie. Wer `tika-parsers-standard-package` in einer anderen Version einbindet als `tika-core`, landet bei Versionskonvergenzfehlern. Dagegen stellt das Projekt das BOM-Artefakt `tika-bom` bereit, das man im `dependencyManagement`-Abschnitt mit `type` `pom` und `scope` `import` einträgt. Danach tragen die einzelnen Tika-Abhängigkeiten keine Version mehr; die BOM zieht sie nach.

In Gradle lautet das Gegenstück `implementation(platform("org.apache.tika:tika-bom:4.x.y"))` zusammen mit `implementation("org.apache.tika:tika-parsers-standard-package@pom")`. Alle Beispiele in der README arbeiten mit dem Versionsmuster 4.x.y, die konkrete Zahl muss man selbst einsetzen.

Auffällig am Parserpaket ist der Typ: Es wird als `pom` eingebunden, nicht als JAR. Das Paket zieht die Parser als transitive Abhängigkeiten, statt sie einzubetten. Wer ausschließlich PDF verarbeiten will, lädt damit trotzdem das komplette Standardpaket und dessen transitive Baum an Parserbibliotheken. Das ist ein echter Kostenfaktor für Container-Images und für die Angriffsfläche, und die README nennt keinen Weg, das Standardpaket auf einzelne Formate zu beschneiden.

Quellbuild mit mvnw: -Pfast, -T1C und der ossindex-Abbruch

Tika baut auf Java 17 mit Maven 3. Im Repository liegt ein Maven-Wrapper (`mvnw`, unter Windows `mvnw.cmd`), der bei Bedarf die passende Maven-Version nachlädt. Der vollständige Build ist `./mvnw clean install`; danach liegt eine ausführbare JAR unter `tika-app/target/tika-app-*.jar`, die mit `--help` ihre Optionen auflistet.

Wer nur ein Unterprojekt braucht, baut mit `./mvnw clean install -am -pl :tika-server-standard` und spart den vollständigen Reaktor-Durchlauf. Das ist für jemanden, der lediglich den Server betreiben will, der realistische Weg.

Für die Entwicklungsiteration nennt die README drei Hebel. `-Pfast` überspringt Tests, Checkstyle und Spotless. `-T1C` baut mit einem Thread pro Kern. Der Maven Daemon `mvnd` hält eine warme JVM und ist laut README ein direkter Ersatz für `mvn`, mit zwei- bis dreifach schnelleren Wiederaufbauten; auf macOS installiert man ihn per `brew install mvndaemon/tap/mvnd`. Kombiniert ergibt das `mvnd clean install -Pfast -T1C`. Gemessene Zeiten nennt die README nicht, die Beschleunigung bleibt eine Projekteinschätzung.

Zwei dokumentierte Stolpersteine sind im Alltag relevanter als die Tuning-Flags. Das `ossindex-maven-plugin` bricht den Build ab, wenn für eine Abhängigkeit inzwischen eine Schwachstelle bekannt ist; dann hilft `-Dossindex.skip`. Und `tika-integration-tests` setzt Docker voraus, ohne Docker werden diese Tests übersprungen. Einzelne Tests schaltet man mit `-Dtest=\!UnpackerResourceTest#testPDFImages` ab. Beim Bauen eines alten Tags wie 3.0.1 gilt dasselbe: Zwischen Tag-Datum und Build-Datum neu gemeldete Schwachstellen stoppen den Build, sofern man das Plugin nicht überspringt.

Reproduzierbarkeit: project.build.outputTimestamp und der Doppelbuild

Tika unterstützt reproduzierbare Builds. Gleicher Quellcode und gleiche JDK-Version sollen byte-identische Artefakte erzeugen, unabhängig von Maschine und Bauzeit. Dafür ist `project.build.outputTimestamp` in `tika-parent/pom.xml` gesetzt, und alle Maven-Plugins sind auf deterministische Ausgaben konfiguriert.

Der Nachweis läuft in zwei Stufen. `./mvnw artifact:check-buildplan` prüft, ob der Build-Plan die Voraussetzungen erfüllt. Der eigentliche Beweis ist ein Doppelbuild: `./mvnw clean install -DskipTests`, dann `~/.m2/repository/org/apache/tika` nach `tika-build-1` verschieben, erneut bauen und mit `diff -r tika-build-1 ~/.m2/repository/org/apache/tika` vergleichen.

Welche JDK-Versionen das Projekt tatsächlich gegen die Reproduzierbarkeit testet, gibt die README nicht an. Wer den Nachweis für eine Audit-Dokumentation braucht, sollte das Diff auf dem eigenen JDK fahren, statt der Zusage zu glauben. Für Tika wiegt das schwerer als bei einer kleinen Bibliothek, weil die Parser-Artefakte aus dem Baum oft über Mirror bezogen werden und ein byte-identischer Nachbau die einzige praktische Prüfung ist, ob ein Artefakt zum veröffentlichten Quelltag passt.

Grenzen von Tika: Formatbreite gegen Kontrollverlust, Apache PDFBox als Alternative

Die Stärke von Tika ist eine einzige Schnittstelle für Formaterkennung und Extraktion. Genau daraus folgt die Grenze: Die Wahl der Parser und ihrer Versionen liegt beim Standardpaket, nicht beim Aufrufer. Ein Parser-Update innerhalb von `tika-parsers-standard-package` kann die Ausgabe für ein Format verändern, ohne dass sich eine Zeile des eigenen Codes ändert. Wer über die BOM einbindet, bekommt genau diese Kopplung und sollte Tika-Versionen wie Parser-Upgrades behandeln, also mit einem festen Satz Testdokumente gegenprüfen.

Wer nur PDF verarbeitet, findet in Apache PDFBox das engere Werkzeug. Dort arbeitet man direkt auf dem PDF-Objektmodell, entscheidet selbst, welche Strukturen gelesen werden, und hat keine Detektion für Office-Formate, Archive oder E-Mail-Anhänge. Das ist weniger Komfort bei unbekanntem Input, aber mehr Vorhersagbarkeit bei bekanntem Input. Die Entscheidung ist damit keine Frage der Qualität, sondern der Eingabeverteilung: unbekannte Formate sprechen für Tika, ein konstanter PDF-Strom für PDFBox.

Ein dritter Punkt betrifft den Vertrieb. Die Distribution enthält mit den Bouncy-Castle-Bibliotheken kryptografische Software, die für verschlüsselte PDFs gebraucht wird. Die README klassifiziert die Software nach ECCN 5D002.C.1 und als unter die TSU-Ausnahme fallend, und sie rät, die Gesetze des eigenen Landes zu prüfen. Wer Tika in ein reguliertes Umfeld ausliefert, sollte diese Einstufung nicht als Formalie abtun.

Zur Community nennt die README Mailinglisten für Anwender (`user@tika.apache.org`) und Entwicklung (`dev@tika.apache.org`) sowie Apache JIRA unter dem Projekt TIKA für Fehlermeldungen; Sicherheitsfälle laufen über die eigene Tika-Sicherheitsseite und `SECURITY.md`. Antwortzeiten, Contributor-Zahlen oder Freigabetakte nennt die README nicht.

Redaktionelles Fazit

Tika passt zu Teams, die unbekannte Binärdokumente in großen Stückzahlen in Text überführen müssen und dafür eine einzige Schnittstelle statt einer Parser-Sammlung wollen. Wer ausschließlich PDF verarbeitet und die Ausgabe exakt kontrollieren muss, ist mit Apache PDFBox besser bedient, und wer noch auf Tika 2.x steht, betreibt eine seit April 2025 nicht mehr gepflegte Linie. Vor dem Wechsel auf 4.x zu klären: läuft die eigene JVM auf Java 17, lässt sich `tika-config.xml` durch die neue JSON-Konfiguration ersetzen, sind die selbst gesetzten Metadatenschlüssel bereits mit Namensraum präfixiert, und verkraften die nachgelagerten Verarbeiter Markdown statt Rohtext. Der erste konkrete Test ist ein Aufruf von `java -jar tika-app-<version>.jar -J` auf ein Dokument mit Anhängen, gefolgt von einem Blick, ob die erwarteten Schlüssel wirklich im JSON auftauchen.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository