Warum Java «NoClassDefFoundError: javax/xml/bind/JAXBException» schreit und was man 2025 dagegen tun kann?
\n\nSind Sie jemals in die Situation geraten, dass Ihre Java-Anwendung, die gestern noch wie am Schnürchen lief, heute mit einem beängstigenden Fehler java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException abstürzt? Wenn ja, sind Sie nicht allein. Diese Frage hat tausende Aufrufe auf Stack Overflow gesammelt, und die Nachfrage nach einer Lösung lässt auch 2025 nicht nach. Die Sache ist, dass das Problem mit grundlegenden Änderungen im Java-Ökosystem zusammenhängt, die vor einigen Jahren stattfanden, aber Entwickler bis heute verfolgen.
In diesem Artikel geben wir nicht nur den «Fisch» – wir analysieren, warum dieser Fehler auftritt, und zeigen drei zuverlässige Methoden, um ihn zu beheben. Sie erfahren, wie Sie Maven, Gradle oder JVM-Argumente richtig konfigurieren, damit Ihre Anwendung wieder funktioniert. Los geht's!
\n\nDie Wurzel des Übels: Java 9 und das Modulsystem
\n\nAlles begann mit Java 9 (veröffentlicht 2017). In dieser Version führte Oracle das Modulsystem (Project Jigsaw) ein. Viele Pakete, die zuvor Teil der Standardbibliothek (JDK) waren, wurden in separate Module ausgelagert oder ganz entfernt. Einer dieser «Ausgestoßenen» war das Paket javax.xml.bind (JAXB – Java Architecture for XML Binding).
In Java 8 und älter war JAXB «out of the box» verfügbar. Ab Java 9 wurde es optional. Und in Java 11 wurde es sogar vollständig aus dem JDK entfernt. Wenn Sie Code schreiben, der javax.xml.bind.JAXBContext, JAXBException oder Marshaller verwendet, und ihn auf Java 11+ ausführen, erhalten Sie garantiert einen NoClassDefFoundError.
Wichtig: NoClassDefFoundError unterscheidet sich von ClassNotFoundException. Ersterer tritt auf, wenn die Klasse zur Kompilierzeit verfügbar war, aber zur Laufzeit verschwunden ist. Letzterer, wenn die Klasse überhaupt nicht gefunden wird.
Szenario: Wie das Problem in der Praxis aussieht
\n\nStellen Sie sich vor, Sie haben eine einfache Klasse zur Arbeit mit XML:
\n\nimport javax.xml.bind.JAXBContext;\nimport javax.xml.bind.JAXBException;\nimport javax.xml.bind.Marshaller;\n\npublic class XmlProcessor {\n\n public void convertToXml(Object obj) throws JAXBException {\n JAXBContext context = JAXBContext.newInstance(obj.getClass());\n Marshaller marshaller = context.createMarshaller();\n marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE);\n // ... Ausgabelogik\n }\n}\n\nSie kompilieren diesen Code auf Java 8 – alles okay. Dann aktualisieren Sie das JDK auf Version 11 oder 17, starten die Anwendung und sehen:
\n\nException in thread "main" java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException\n at XmlProcessor.convertToXml(XmlProcessor.java:6)\n ...\n\nKommt Ihnen bekannt vor? Jetzt lösen wir das Problem.
\n\nMethode 1: JAXB API als externe Abhängigkeit hinzufügen (empfohlen)
\n\nDer korrekteste und modernste Ansatz ist, explizit anzugeben, dass Ihre Anwendung JAXB verwendet. Dazu müssen Sie die Bibliothek über ein Build-System (Maven oder Gradle) einbinden.
\n\nFür Maven (pom.xml)
\n\nFügen Sie in <dependencies> hinzu:
<dependency>\n <groupId>jakarta.xml.bind</groupId>\n <artifactId>jakarta.xml.bind-api</artifactId>\n <version>4.0.2</version>\n</dependency>\n<dependency>\n <groupId>org.glassfish.jaxb</groupId>\n <artifactId>jaxb-runtime</artifactId>\n <version>4.0.5</version>\n <scope>runtime</scope>\n</dependency>\n\nBeachten Sie: Seit Jakarta EE 9 (Juni 2021) wurde das Paket javax.xml.bind in jakarta.xml.bind umbenannt. Wenn Ihr Code alt ist und javax.* verwendet, können Sie trotzdem