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§ion=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
signature.asc
Description: PGP signature
