On Thu, 21 May 2026 12:09:40 GMT, Andrew Dinn <[email protected]> wrote:
> Well, yes, but I can see the other side of this. The problem with not > automating testing on Windows/AArch64 is that changes made by programmers who > develop on Linux/MacOS keep on breaking Windows without them or those > actually working on Windows/AArch4 knowing about it. So the Windows devs end > up running around with a brush and shovel continually trying to locate and > clean up the ... err, ... detritus. Yeah, I tend to agree with @adinn on this one. Windows/AArch64 is still being broken regularly in tip, which in itself demonstrates the need for continuous CI coverage. Without automated testing, regressions introduced by developers primarily working on Linux/macOS often go unnoticed until much later, leaving the relatively small number of Windows/AArch64 contributors to continually track down and clean up the fallout. I’d also point out that we’re starting to see meaningful growth in Windows on Arm adoption. Qualcomm’s Snapdragon X platform is now shipping broadly across major OEMs including Dell, Lenovo, HP, ASUS and Microsoft Surface devices, and Microsoft has been heavily pushing Copilot+ PCs as part of the next generation Windows ecosystem. Obviously this is not happening at the same speed or scale as the Apple Silicon transition did with macOS M-series devices, but Windows does appear to be following a similar longer-term trajectory where Arm64 gradually becomes a mainstream laptop architecture rather than a niche platform. That said, I completely agree that we should remain disciplined around GHA resource usage. I think the important distinction here is that this isn’t about adding “nice to have” testing coverage, it’s about preventing a supported platform from regressing continuously due to lack of signal. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31102#issuecomment-4508509436
