AW: The future of 32-bit?

Tue Apr 8 14:46:44 UTC 2025

On 2025-04-04 12:25, Doerr, Martin wrote:

> Hi all,
>
> even if we deprecate 32 bit now, arm32 will still be usable with JDK 
> 25 LTS for quite some time.
>
> The big question is if there will still be a significant demand in 2 
> years.
>
> I also wonder when other projects will terminate arm32 support.
>
This ^^^.

The question is not *if* we should stop supporting 32-bit, but *when*. I 
don't see anyone arguing that 32-bit platforms have a long-term future. 
We can keep the 32-bit JDKs on life support, for a longer or a shorter 
time, but frankly, that is what it is.

Dropping 32-bit completely somewhere between now and the next LTS 
release might perhaps be a good idea.

As with any other platforms in the JDK, the remaining 32-bit support 
(arm-32 and zero) should have a sponsor, someone (organization or 
company) backing it up. That is the general requirement we have for 
adding a new platform, and we should have the same requirement for 
keeping old platforms in. If we have such a sponsor, then the onus is on 
them to keep the platform up to date with continuous development of the 
JDK. And if no-one is willing to step up and assume such a role, well, 
that is a clear indication that while it might be "nice to have" 32-bit 
support, no-one is willing to pay the price for it. And if so, it should go.

/Magnus

>
> Best regards,
>
> Martin
>
> *Von: *jdk-dev <jdk-dev-retn at openjdk.org> im Auftrag von Johan Vos 
> <johan.vos at gluonhq.com>
> *Datum: *Freitag, 4. April 2025 um 11:17
> *An: *Thomas Stüfe <thomas.stuefe at gmail.com>
> *Cc: *JDK Dev list <jdk-dev at openjdk.org>
> *Betreff: *Re: The future of 32-bit?
>
> Hi Thomas, all,
>
> At the OCW workshop, I expressed my worries about removing all 32-bit 
> code, because I feared it would impact the ability to distribute Java 
> apps to mobile devices (via the existing stores). As someone pointed 
> out, at the very least 32-bit versions are not a requirement anymore. 
> I did a bit of research, and while there are still 32-bit devices in 
> the field, the 2 major stores are pushing for 64-bits, and 
> discouraging 32 bits -- something we would call 
> @Deprecated(forRemoval="true"). As a consequence, zero-32 code is no 
> requirement for iOS, and arm-32 is no requirement for Android.
>
> There are still usecases for the Pi Zero (v1) and older Raspberry Pi 
> devices (< 3). I have no idea about the installed base of those 
> devices, but I believe it is possible that this would be the largest 
> group that will suffer if 32-bit support was halted.
>
> Having said that, I fully agree there is lots of additional work 
> required to keep 32-bit support (the (un)compressed classpointers are 
> a good example indeed). Though situation.
>
> - Johan
>
> On Fri, Apr 4, 2025 at 9:17 AM Thomas Stüfe <thomas.stuefe at gmail.com> 
> wrote:
>
>     Hi,
>
>     Continuing our discussion at the last FOSDEM workshop, I would
>     like to know what we think about the future of 32-bit support.
>
>     Supporting 32-bit became a lot more cumbersome after the x86 port
>     was removed. Before, one could easily build 32-bit on the
>     ubiquitous x64 platforms with --target-bits=32; that is not an
>     option anymore.
>
>
>     We have two remaining 32-bit platforms, at least in theory:
>
>     - arm32
>     - zero 32-bit
>
>     Zero 32-bit has been broken for a long while now; see
>     https://bugs.openjdk.org/browse/JDK-8353699. I try this
>     occasionally and don't remember the last time it built successfully.
>
>     Arm32 is the last bastion of serious 32-bit support, and the last
>     option for testing 32-bit coding. So, one needs to build arm32
>     (best done via crossbuild), then spin up an arm32 system to test
>     the changes. I do this with a slow-as-molasses Raspberry. It is
>     not fun.
>
>     Unfortunately, maintaining 32-bit is not as easy as "make sure it
>     builds and fix smaller things". It requires real development,
>     especially in the context of ongoing object header work.
>
>     32-bit also means we need to keep some form of uncompressed class
>     pointers around, which makes the eventual removal of uncompressed
>     class pointers (see [2]) more difficult. The current plan is to
>     implement some sort of fake-compressed-class-pointer mode [3],
>     which sounds easy in theory but is still tricky work I'd rather avoid.
>
>     Keeping up 32-bit development in the face of dwindling options to
>     build and test is a struggle. It has been a struggle for some time
>     now. Even the comparatively well-maintained arm32 platform had
>     periodic weeks of brokenness after heavy upstream changes. And
>     this is not intended to diminish the effort put in by the
>     arm32-maintainers. They are few, and they do good work.
>
>     But I expect this periodic brokenness to worsen now after the
>     removal of x86. This is not a good situation.
>
>     Thank you, Thomas
>
>     [1] https://bugs.openjdk.org/browse/JDK-8353699
>     [2] https://bugs.openjdk.org/browse/JDK-8350754
>     [3]
>     https://bugs.openjdk.org/browse/JDK-8350754?focusedId=14757275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14757275
>     <https://bugs.openjdk.org/browse/JDK-8350754?focusedId=14757275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14757275>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20250408/404fa6a2/attachment-0001.htm>