Das Ende von 32-Bit Java

Warum der x86-32-Port aus dem JDK verschwindet, was das für Windows 32-Bit bedeutet und welche Möglichkeiten noch bestehen.

Uwe Rittmeyer

TL;DR

Bei Oracle JDK und Eclipse Temurin ist Java 17 das letzte Release mit 32-Bit-Build für Windows. Ab Java 21 liefern diese Distributionen keine 32-Bit-x86-Binaries mehr.
Ursache ist kein einzelnes Release, sondern eine mehrstufige Abkündigung im OpenJDK: Deprecation in JDK 21 (JEP 449 ), Entfernung des Windows-Ports in JDK 24 (JEP 479 ) und vollständige Entfernung des x86-32-Ports in JDK 25 (JEP 503 ).
Betroffen ist ausschließlich 32-Bit-x86. Der 32-Bit-ARM-Port (ARM32 / ARMv7) bleibt erhalten und ist etwa für ältere Raspberry-Pi-Modelle relevant.
"Ab Java 21 gibt es kein 32-Bit mehr" ist nur distributionsabhängig korrekt. BellSoft Liberica liefert für Java 21 weiterhin 32-Bit-Builds (Windows, Linux x86 und ARM32).

Worum geht es?

Die Aussage "Java 17 ist die letzte 32-Bit-Version" kursiert häufig – und ist im Alltag oft korrekt, aber technisch ungenau. Genauer betrachtet handelt es sich um zwei verschiedene Ebenen, die gern vermischt werden:

Verfügbarkeit fertiger Binaries bei einer bestimmten Distribution
Existenz des 32-Bit-Ports im OpenJDK-Quellcode

Beides hat einen unterschiedlichen Zeitplan.

Wer Java über Eclipse Temurin oder Oracle bezieht, findet für Windows tatsächlich kein 32-Bit-Build jenseits von Java 17. Der eigentliche Abschied von 32-Bit-x86 im OpenJDK selbst vollzog sich jedoch erst später und in mehreren Schritten.

Die technischen Gründe

Hinter der Entscheidung steht weniger ein einzelnes Argument als eine Summe von Faktoren, die im OpenJDK -Projekt über mehrere JEPs hinweg dokumentiert sind:

Virtual Threads ohne Mehrwert. Die in JDK 21 finalisierten Virtual Threads (Project Loom ) fallen auf 32-Bit-x86 auf klassische Kernel-Threads zurück. Der zentrale Vorteil von Loom entfällt damit auf dieser Plattform.
Wartungsaufwand bei neuen Features. Die Parität zu modernen Funktionen wie der Foreign Function & Memory API, der Vector API oder neuen GC-Mechanismen für 32-Bit-x86 nachzuziehen, bindet erhebliche Ressourcen – bei zugleich schwindendem Nutzen.
Fehlende Maintainer. Für eine nachhaltige, performante 32-Bit-x86-Implementierung fanden sich im Projekt keine Freiwilligen, die diese Rolle dauerhaft übernehmen wollten.
Auslaufende Plattform. Windows 10 als letztes Windows-Betriebssystem mit 32-Bit-Betrieb erreichte im Oktober 2025 das End-of-Life. Damit entfällt die wichtigste Zielplattform für 32-Bit-x86 unter Windows.

Im Ergebnis überwog der Wartungsaufwand den praktischen Nutzen – ein klassischer Fall von „Legacy entfernen, um die Weiterentwicklung zu beschleunigen“.

Der Zeitstrahl: Von der Deprecation zur Entfernung

Die populäre Verknüpfung "Java 21 = kein 32-Bit" ist eine Verkürzung. In JDK 21 wurde der Port nicht entfernt, sondern lediglich abgekündigt. Genau dieses Signal veranlasste Distributoren wie Adoptium, ab Java 21 keine 32-Bit-Windows-Builds mehr zu erstellen. Im Folgenden der vollständige Ablauf:

JEP	Release	Schritt
JEP 449	JDK 21 (Sept. 2023)	Windows-x86-32-Port als deprecated for removal markiert (Build erzeugt eine unterdrückbare Fehlermeldung)
JEP 479	JDK 24 (März 2025)	Windows-x86-32-Port entfernt
JEP 501	JDK 24 (März 2025)	Linux-x86-32-Port (letzter verbleibender x86-32-Port) als deprecated for removal markiert
JEP 503	JDK 25 (Sept. 2025)	x86-32-Port vollständig entfernt

Daraus folgt: Im OpenJDK -Mainline existierte der Windows-32-Bit-Port noch bis einschließlich JDK 23, der Linux-32-Bit-x86-Port bis einschließlich JDK 24. Erst ab JDK 25 ist 32-Bit-x86 endgültig verschwunden.

Wichtige Differenzierung: `x86` ist nicht gleich `32-Bit`

Eine häufige Fehlinterpretation lautet, Java habe "32-Bit aufgegeben". Korrekt ist: Entfernt wurde der 32-Bit-x86-Port, also Intel/AMD-Prozessoren im 32-Bit-Modus.

Der 32-Bit-ARM-Port (ARM32 / ARMv7) ist davon ausdrücklich nicht betroffen und bleibt bestehen. Das ist insbesondere für eingebettete und ältere Systeme relevant, wie etwa Raspberry-Pi-Modelle mit 32-Bit-Betriebssystem. Wer dort auf 32-Bit angewiesen ist, hat weiterhin Optionen. Zusätzlich existiert der architekturunabhängige Zero-Port, der 32-Bit-x86 auch nach der Entfernung des optimierten HotSpot-Ports prinzipiell ausführen kann, allerdings ohne dessen Performance.

Hersteller-Überblick: Wer liefert was?

Die entscheidende Erkenntnis, ob ein 32-Bit-Build verfügbar ist, hängt nicht von "Java" als Ganzem ab, sondern von der gewählten Distribution. Die folgende Übersicht fasst die Lage für die gängigen OpenJDK -Builds zusammen (Stand der Recherche: 2026-06-30).

Distribution	32-Bit x86 (Windows)	32-Bit x86 (Linux)	32-Bit ARM	Anmerkung
Oracle	bis Java 8	–	–	Ab JDK 9 ausschließlich 64-Bit
Eclipse Temurin	bis Java 17	–	–	Ab JDK 21 kein Windows-x86-32-Build mehr
Amazon Corretto	bis Corretto 8	–	–	Moderne Versionen 64-Bit; Schwerpunkt Server/Cloud
Azul Zulu	Java 8 & 11	Java 8 & 11	über Embedded-Builds	Neuere Versionen überwiegend 64-Bit
BellSoft Liberica	bis Java 21	bis Java 21	ARM32 / ARMv7	Breiteste Plattformabdeckung, Embedded-Fokus

BellSoft Liberica ist der Grund, warum die pauschale Aussage "ab Java 21 kein 32-Bit" nicht haltbar ist. Liberica 21 wird ausdrücklich für Windows 32, Linux x86 sowie ARMv7 (inklusive Raspberry Pi 2 & 3) angeboten und deckt damit als einzige der großen Distributionen das gesamte 32-Bit-Spektrum bis in die aktuelle Java 21 LTS-Generation ab.
Ab JDK 25 entfällt der x86-32-Port upstream (JEP 503 ). Damit endet auch für die meisten Distributionen die Möglichkeit, neue 32-Bit-x86-Builds zu erstellen. 32-Bit-ARM bleibt davon unberührt.
Die exakte Verfügbarkeit einzelner Pakete ändert sich laufend. Vor einer Migrationsentscheidung empfiehlt sich daher stets ein Blick auf die jeweils aktuelle Download-Seite des Anbieters.

Was bedeutet das in der Praxis?

Für die meisten Projekte ist der Wegfall folgenlos, da Server-, Cloud- und Desktop-Umgebungen längst auf 64-Bit laufen. Handlungsbedarf besteht vor allem in zwei Konstellationen:

Bindung an 32-Bit-native Bibliotheken. Ein 64-Bit-Prozess kann unter Windows keine 32-Bit-DLLs laden. Anwendungen, die auf solche Integrationen angewiesen sind, lassen sich nicht ohne Weiteres auf eine 64-Bit-JVM umstellen. Mögliche Wege sind die Migration der nativen Komponenten auf 64-Bit oder die Auslagerung der 32-Bit-Funktionalität in einen separaten Prozess mit Remote-API.
Eingebettete 32-Bit-Hardware. Hier lohnt der Blick auf ARM32-fähige Distributionen oder auf Anbieter mit explizitem Embedded-Fokus.

Wer auf einer 32-Bit-x86-Plattform bleiben muss, kann zudem auf einer älteren JDK-Generation (vor JDK 25) mit dem bekannten Nachteil verharren, dass Sicherheitsupdates für nicht mehr gepflegte Versionen ausbleiben. Eine zeitnahe Migrationsplanung ist daher in jedem Fall ratsam.

Fazit

Das "Aus" für 32-Bit-Java ist genauer gesagt ein Aus für den 32-Bit-x86-Port. Schrittweise abgekündigt ab JDK 21 (JEP 449 ) und endgültig entfernt in JDK 25 (JEP 503 ). Die verbreitete Faustregel "Java 17 ist die letzte 32-Bit-Version" trifft auf Oracle und Temurin zu, gilt aber nicht universell: 32-Bit-ARM besteht fort, und Distributionen wie BellSoft Liberica liefern auch für Java 21 weiterhin 32-Bit-Binaries. Entscheidend ist somit nicht die Java-Version selbst, sondern die Kombination aus Architektur und gewählter Distribution.

Happy Porting 👨🏼‍💻👩🏻‍💻🚀