Windows/Zero

Mon Apr 28 17:18:32 UTC 2025

On 10:59 Thu 24 Apr     , Kim Barrett wrote:
> On 4/22/25 8:46 AM, Julian Waters wrote:
> > Hi all,
> > 
> > Zero currently cannot compile on Windows, and to my knowledge, has
> > never been able to compile on Windows. [...]
> >

I don't recall anyone showing interest in having it compile on Windows
in the best part of twenty years that Zero has existed. As Thomas &
Kim have said, it is primarily used for supporting new architectures
which don't yet have a JIT. The emphasis is on the architecture side
of the platform, not the operating system.

The only architectures Windows currently supports are x86 and aarch64.
x86 has had a JIT since OpenJDK's inception and the aarch64 port was
developed for Linux first, from which point it made more sense to add
Windows support to the existing JIT than for Zero.

I have seen Zero used to build on plenty of architectures (ppc, s390,
mips, alpha) on the Linux side. But, performance wise, it really only
makes sense to do this when there is no other option and you need to
ship a build of some form.

Zero was first developed at Red Hat because we had a problem to solve:
we needed to ship OpenJDK on all the architectures that used to ship
with gcj (x86, ppc, s390) but, at the time, OpenJDK only had x86 and
SPARC ports. Zero was a way to provide an OpenJDK build on PPC & s390
in RHEL, even if most end users eventually went for another third
party JDK that did have a JIT.

OpenJDK has since gained PPC and s390 JITs and this is why Zero does
not get as much testing as it once did. It's still useful to maintain
it for bootstrapping new ports, but the only place we regularly ship
builds using Zero is to support s390 on OpenJDK 8, where it doesn't
have a JIT. It looks like Debian builds on mips [0], so they may have
more experience with Zero on the newer JDKs.

It's not clear to me what your aim is here. If you want a way to keep
OpenJDK working on Windows x86-32, then I would suggest it makes more
sense to revert the JIT removal than try to make Zero work.  It's
likely to be a battle either way, given 32-bit support is being
removed across the board, but maintaining a JIT would be a more
satisfying end result. Unless performance has improved dramatically
since I last tried, I can't see anyone wanting to use Zero day to day
to run Java programs.

If you're interested in Zero on Windows from an academic perspective,
then it might make more sense to target the update releases where
32-bit support is still maintained (and especially 8u where Zero
is also being regularly built by us).

I had a look over your patch and it seems to be trying to solve three
problems at once: building Zero on Windows, building on x86-32 and
building on Windows with gcc. Building an update release with the
supported Visual Studio compiler may well remove some of the issues
that are not down to Zero at all. I find it especially worrying to see
huge chunks of Zero code outside the Windows area deleted and some
return values replaced with null pointers.

> > I started work again recently to get Zero working with VC. [...]
> > 
> > I'd like to float the idea of supporting Windows/Zero properly.
> > [...]
> > 
> > 
> > Thoughts?
> 
> Quoting from https://openjdk.org/jeps/479 "Remove the Windows 32-bit x86 Port":
> 
> "Windows 10, the last Windows operating system to support 32-bit operation,
> will reach End of Life in October 2025."
> 
> That suggests the community of 32-bit Windows users is very small, and will
> only get smaller.  The delivery of that JEP and the fact that zero has never
> worked on Windows at all suggests the community of 32-bit Windows users with
> new development needs is essentially nonexistent.
>

Yes. I'd add to this that anyone who wants to still run the JDK on
x86-32 Windows is unlikely to be satisfied with Zero as a replacement
for a JIT build.

It also implies a further niche of those who really want 24 and later,
because 8, 11, 17 & 21 are still being actively maintained and support
Windows on x86-32.  My first question would be why vendors don't seem
to even be offering x86-32 Windows builds of 21 [1] if there is a
demand for a JDK there.

> So providing a way to run new versions of Java on 32-bit Windows doesn't seem
> to me to be at all motivating.
> 
> A port needs an active community to be considered alive and supported.  I
> don't see that here.  All I see is potential costs, with no demonstrated gain.
>

I agree. We've had our fair share of ports over the years that have
been supported at one time and then become broken. Shark springs to
mind [1].  Keeping a port working is a full time job.

> I don't think "Ideally, Zero should run on any platform, so it not running on
> Windows would be surprising" is a good reason.  I think the purpose of zero is
> to provide a stepping stone toward support for a new platform where none
> currently exists.  That's not what we have here.

Yes, 'platform' here should really be 'architecture'. The primary OS
for Zero was always Linux, and if it has worked on other POSIX
systems, that's been more a side effect of their similarity leading to
a lot of shared code.

The only practical case I see for Zero on Windows is if it is
someone's chosen platform to develop a port to a new architecture, as
Thomas mentioned.  Given the need for Windows to also support said
architecture, I would only expect such an effort to come from
Microsoft.

> 
> The addition of zero-specific conditionalization in shared code in this work
> seems quite suspicious, given that zero currently works for non-Windows.
>

I find this curious as well. I expect some of it is related to
building on Windows with gcc, but I would certainly need a very strong
reason to change code we've been using for nearly two decades to
return null pointers.

> Sorry to be raining on your parade, but this doesn't seem useful to me.
> 

Likewise. We might be able to be more positive if we knew what your
end goal was :)

[0] https://packages.debian.org/search?keywords=openjdk-21&searchon=names&suite=testing&section=all
[1] https://adoptium.net/en-GB/marketplace/?os=windows&arch=x86&version=21
[2] https://bugs.openjdk.org/browse/JDK-8171853

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Principal Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

Please contact via e-mail, not proprietary chat networks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20250428/ecfeb985/signature-0001.asc>