JEP 501: Deprecate the 32-bit x86 Port for Removal

Summary

Deprecate the 32-bit x86 port, with the intent to remove it in a future release. This will thereby deprecate the Linux 32-bit x86 port, which is the only 32-bit x86 port remaining in the JDK. It will also, effectively, deprecate any remaining downstream 32-bit x86 ports. After the 32-bit x86 port is removed, the architecture-agnostic Zero port will be the only way to run Java programs on 32-bit x86 processors.

Goals

• Unblock new features that require platform-specific support from having to implement 32-bit x86 fallbacks.

• Mark the port, and related port-specific features, as deprecated for removal in the relevant documentation, configuration scripts, and test jobs.

Non-Goals

• It is not a goal to deprecate any other 32-bit port.

Motivation

As noted in a recent discussion involving the current 32-bit x86 maintainer and interested parties, the cost of maintaining this port outweighs the benefits. Maintaining parity with new features, such as Loom, the Foreign Function & Memory API (FFM), the Vector API, late GC barrier expansion, etc., is a major opportunity cost. Deprecating and eventually removing the port would allow OpenJDK developers to accelerate the development of new features and enhancements.

Deprecating this port in JDK 24 will allow us to remove it in JDK 25.

Description

An attempt to configure a 32-bit x86 build will produce:

$ bash ./configure
...
checking compilation type... native
configure: error: The 32-bit x86 port is deprecated and may be removed in a future release. \
Use --enable-deprecated-ports=yes to suppress this error.
configure exiting with result code 1
$

The build configuration option --enable-deprecated-ports=yes will suppress the error and continue:

$ bash ./configure --enable-deprecated-ports=yes
...
checking compilation type... native
configure: WARNING: The 32-bit x86 port is deprecated and may be removed in a future release.
...
Build performance summary:
* Cores to use:   32
* Memory limit:   96601 MB

The following warnings were produced. Repeated here for convenience:
WARNING: The 32-bit x86 port is deprecated and may be removed in a future release.
$

There will be no guarantee that the port will build, much less function.

In order to unblock mainline development, we have already disabled Linux 32-bit x86 builds in the GitHub Actions defined in the JDK source repository (8338286). We will completely remove these build jobs as part of this deprecation.

Risks and Assumptions

• There is no pressing industry need for 32-bit x86 with modern JDKs — We assume that the x86 world has moved firmly to the 64-bit realm. No new 32-bit-only x86 hardware is being manufactured. The remaining 32-bit x86 deployments are legacies. Industry support has dwindled to match this reality. Windows 10, the last Windows operating system to support 32-bit operation, will reach End of Life in October 2025, and the Windows 32-bit x86 port has already been removed from the JDK (JEP 479). Debian plans to stop supporting 32-bit x86 in the near future.

• There is enough margin for backport safety with releases that still support 32-bit x86 — Not having the Linux 32-bit x86 port in the main line means that backports from the main line to actively supported LTS releases will be more complicated, since they will have to be reconciled with the Linux 32-bit x86 port still in those releases. We assume that the majority of older Linux 32-bit x86 application stacks are still on JDK 8, to which we do not backport often, which mitigates this risk. There will still be additional work for Linux 32-bit x86 maintainers in newer LTS releases to make sure their builds work.

• The maintenance of other 32-bit ports is not significantly affected — Linux 32-bit x86 provides a vehicle for maintaining 32-bit cleanliness, which indirectly benefits the maintenance of other 32-bit ports, notably ARM32. We assume that we can continue to maintain the ARM32 port easily enough.

• Fallback options can be tested separately — We assume that existing fallback mechanisms, such as Loom's 1:1 scheduler and FFM’s fallback linker, can be tested separately, without the burden of maintaining the whole Linux 32-bit x86 port.

Alternatives

The alternative would be to continue to support 32-bit x86. This would require active maintainers who can provide a sustainable and performant implementation of virtual threads, as well as future JEPs, to ensure that the JDK on 32-bit x86 continues to meet the expectations of Java developers. There are no prospective maintainers who are willing to take that role.