Du sitzt vor deinem Rechner, willst gerade dein neuestes Java-Projekt starten oder eine neue Bibliothek ausprobieren, und plötzlich knallt es in der Konsole. Wer schon einmal Software entwickelt hat, kennt diesen Frustmoment. Da steht eine kryptische Fehlermeldung wie Unsupported Class File Major Version 65 und alles steht still. Es ist nervig. Es ist zeitraubend. Aber es ist kein Weltuntergang, wenn man weiß, was hinter den Kulissen von Java eigentlich passiert.
Im Kern sagt dir dein System damit nur eine einzige Sache: Du versuchst, Code auszuführen, der für eine neuere Java-Version kompiliert wurde, als die, die du gerade zum Ausführen benutzt. Die Zahl 65 steht dabei spezifisch für Java 21. Wenn deine Laufzeitumgebung (JRE) oder dein Development Kit (JDK) älter ist als Version 21, versteht sie das Format der Klassendatei schlichtweg nicht. Das ist so, als würdest du versuchen, eine Blu-ray in einen alten DVD-Player zu schieben. Die Hardware erkennt zwar, dass es eine Scheibe ist, kann aber mit den Datenstrukturen darauf nichts anfangen. Erfahren Sie mehr zu einem verwandten Thema: diesen verwandten Artikel.
In der Praxis tritt dieses Problem oft auf, wenn man Gradle oder Maven nutzt. Du ziehst eine Abhängigkeit in dein Projekt, die frisch auf Java 21 aktualisiert wurde. Dein lokaler Rechner läuft aber vielleicht noch auf Java 17 oder – Gott bewahre – Java 11. Schon hast du den Salat. In den nächsten Abschnitten schauen wir uns an, warum Oracle und die OpenJDK-Community diese Versionsnummern so strikt handhaben und wie du deine Umgebung in fünf Minuten wieder flottkriegst.
Was die Zahl 65 über dein Java-Ökosystem verrät
Jede Java-Version hat eine fest zugewiesene Major-Nummer für ihre Klassendateien. Das ist ein interner Standard. Java 8 hatte die Nummer 52. Java 11 sprang auf 55. Java 17 landete bei 61. Und mit dem Release von Java 21 im September 2023 kam eben die 65 ins Spiel. Diese Nummern sind für die Java Virtual Machine (JVM) heilig. Sie dienen als erster Check beim Laden einer Klasse. Wenn die JVM sieht, dass die Version der Datei höher ist als das, was sie selbst unterstützt, bricht sie sofort ab. Das schützt dich davor, dass dein Programm mitten im Betrieb wegen inkompatibler Bytecode-Befehle abstürzt. Netzwelt hat dieses bedeutende Sachgebiet ausführlich analysiert.
Die Verbindung zwischen Bytecode und Laufzeit
Der Compiler übersetzt deinen lesbaren Java-Code in Bytecode. Dieser Bytecode ist theoretisch plattformunabhängig. Er ist aber nicht versionsunabhängig. Ein Compiler von Java 21 nutzt eventuell neue Sprachfeatures oder Optimierungen, die eine JVM von Java 17 nicht kennt. Wenn du also eine Library nutzt, die mit dem JDK 21 gebaut wurde, verlangt diese zwingend nach einer Umgebung, die mindestens diesen Standard beherrscht.
Warum Java 21 ein besonderer Meilenstein ist
Java 21 ist eine Long-Term-Support-Version (LTS). Das bedeutet, viele Firmen stellen gerade jetzt ihre Infrastruktur darauf um. Es ist die Version, die Virtual Threads (Project Loom) und Pattern Matching für Switch-Statements in die stabile Phase gebracht hat. Weil diese Features so bahnbrechend sind, kompilieren immer mehr Entwickler ihre Open-Source-Bibliotheken direkt für Java 21. Wenn du dann mit einer alten Version von IntelliJ oder einer veralteten Jenkins-Pipeline arbeitest, taucht die Fehlermeldung prompt auf. Es ist ein klares Zeichen: Die Welt zieht an dir vorbei, und du musst dein Werkzeugset aktualisieren.
So löst du Unsupported Class File Major Version 65 in deiner IDE
Die meisten Entwickler stolpern in IntelliJ IDEA oder Eclipse über diesen Fehler. Oft liegt es daran, dass zwar ein neues JDK auf dem Rechner installiert ist, die IDE aber noch ein internes, älteres JDK für den Build-Prozess verwendet. Es reicht nicht, Java einfach nur zu installieren. Du musst deiner Entwicklungsumgebung explizit sagen, wo es langgeht.
In IntelliJ findest du die entscheidenden Stellschrauben unter den Projekteinstellungen. Drücke Strg + Alt + Shift + S. Hier musst du prüfen, ob das Project SDK auf Version 21 eingestellt ist. Aber Achtung. Oft ist das nur die halbe Miete. Du musst auch in den Einstellungen für die Build-Tools nachsehen. Wenn du Gradle nutzt, geh zu Settings -> Build, Execution, Deployment -> Build Tools -> Gradle. Dort gibt es ein Feld namens "Gradle JVM". Wenn dort noch "Project SDK" steht und das Projekt auf 17 läuft, wird es krachen. Wähle hier explizit ein JDK 21 aus.
Maven und die Compiler-Konfiguration
Bei Maven-Projekten liegt der Hund oft im maven-compiler-plugin begraben. Wenn dort in der pom.xml ein Target von 21 definiert ist, aber dein lokaler Maven-Prozess mit einem JDK 17 startet, erhältst du genau diesen Fehler. Du kannst deine lokale Maven-Version prüfen, indem du mvn -version im Terminal tippst. Dort steht sofort, welche Java-Version Maven gerade im Griff hat. Wenn dort etwas Kleineres als 21 steht, musst du deine JAVA_HOME Umgebungsvariable anpassen. Das ist oft der entscheidende Punkt, den viele vergessen.
Gradle-Wrapper als Fehlerquelle
Ein sehr häufiges Szenario: Du klonst ein Repo, nutzt den ./gradlew Befehl und es knallt. Warum? Weil der Gradle-Wrapper eine bestimmte Gradle-Version mitbringt, die vielleicht noch gar nicht mit Java 21 kompatibel ist. Um Java 21 reibungslos zu nutzen, brauchst du mindestens Gradle 8.4 oder neuer. Wenn dein Projekt auf Gradle 7.x feststeckt, kann Gradle selbst nicht mit dem JDK 21 laufen, selbst wenn du es installiert hast. Du musst also zuerst den Wrapper aktualisieren. Das machst du mit ./gradlew wrapper --gradle-version 8.5. Danach verschwindet der Fehler meist wie von Geisterhand.
Die Rolle von Build-Servern und CI/CD-Pipelines
Lokal funktioniert alles, aber auf dem Server knallt es? Das ist der Klassiker. GitHub Actions, GitLab CI oder Jenkins laufen oft in Docker-Containern. Wenn dein Docker-Image auf openjdk:17 basiert, dein Code aber mittlerweile gegen Java 21 kompiliert wird, wird die Pipeline gnadenlos scheitern. Ich habe das schon dutzende Male in Projekten erlebt, wo jemand mal eben eine Library aktualisiert hat, ohne an die Build-Infrastruktur zu denken.
Hier hilft nur absolute Konsistenz. Wenn du auf Java 21 setzt, muss das Image in deiner .gitlab-ci.yml oder deinem Dockerfile angepasst werden. Ein Umstieg auf das Eclipse Temurin Image ist hier oft die beste Wahl. Die Community hinter Adoptium leistet großartige Arbeit und liefert stabile Builds für alle gängigen Plattformen.
Versionskonflikte in Microservices
In einer Microservice-Architektur ist das Ganze noch tückischer. Wenn Service A eine Client-Library für Service B bereitstellt und diese mit Java 21 baut, müssen alle Services, die diese Library einbinden, ebenfalls auf Java 21 hochgerüstet werden. Das führt oft zu einem Domino-Effekt. Manchmal ist es daher klüger, die Library mit einem älteren Target zu kompilieren, auch wenn man selbst ein neueres JDK nutzt. In Maven nutzt man dafür das `
