winget upgrade java gets architecture wrong

[q7joey]

Brief description of your issue

If I have a 32 bit version of java (I've tried Amazon and Eclipse) and do winget update of that package, winget will install the current 64 bit version of java and leaves the 32 bit version as is.

Steps to reproduce

Install older 32 bit version of Java
winget update -all

Expected behavior

Updated 32 bit version of java should be installed

Actual behavior

Current 64 bit version of java is installed and old 32 bit version is still installed.

Environment

Windows Package Manager v1.9.25200
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.26100.2314
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.24.25200.0

Winget Directories
-----------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Diag…
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\sett…
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages
Installer Downloads                %USERPROFILE%\Downloads

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled
ProxyCommandLineOptions                   Disabled
DefaultProxy                              Disabled

[stephengillie]

A recent manifest for Eclipse only has the x64 installer described. Is it possible that some or all developers have ended 32-bit support?

[q7joey]

The older java versions (like 8) still have 32 and 64 bit versions. And I can do:
winget install eclipseadoptium.temurin.8.jre -a x86

and get the 32 bit version installed, so winget does seem to know about the 32 bit versions.

[denelon]

I just did an install. The issue is the architecture is in the name, but it's in parenthesis at the end which is something WinGet will often ignore due to inconsistencies about what is put in parenthesis.

I looked at the latest manifest which is using product code and upgrade code.

I installed the n-1 version:

Then I upgraded it to the latest and the architecture was preserved.

Is there any chance you know which version you had installed previously?

[denelon]

It's possible we didn't have a valid manifest for that earlier version for WinGet to use the UpgradeCode so it would have defaulted to the name (minus what's in parenthesis) and the best match for the architecture of the device would have been selected. I'd like to get an exact repro of possible.

[q7joey]

The specific package I was trying to update was Temurin 8.0.362.9. I was just going to run through the process again to document here and now it is updating to the correct 32 bit version. Did some changes happen in the manifests?

[q7joey]

I just tested with Corretto and got the bad behavior, so I think someone must have updated the manifests for Temurin.

PS C:\Users\joey> winget list jre
Name                        Id                    Version   Available Source
----------------------------------------------------------------------------
Amazon Corretto JRE 8 (x86) Amazon.Corretto.8.JRE 1.8.0.362 1.8.0.432 winget
PS C:\Users\joey> winget update amazon.corretto.8.jre
Found Amazon Corretto JRE 8 [Amazon.Corretto.8.JRE] Version 1.8.0.432
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://corretto.aws/downloads/resources/8.432.06.1/amazon-corretto-8.432.06.1-windows-x64-jre.msi
  ██████████████████████████████  38.8 MB / 38.8 MB
Successfully verified installer hash
Starting package install...
Successfully installed
PS C:\Users\joey> winget list jre
Name                        Id                    Version   Source
-------------------------------------------------------------------
Amazon Corretto JRE 8 (x64) Amazon.Corretto.8.JRE 1.8.0.432 winget
Amazon Corretto JRE 8 (x86) Amazon.Corretto.8.JRE 1.8.0.362 winget

[denelon]

I think this is an issue with the manifest(s) rather than the WinGet Client. I'm moving this issue over to winget-pkgs.

[SpecterShell]

I think it is expected, since the x86 and the x64 installers are in the same package (e.g., EclipseAdoptium.Temurin.8.JDK rather than EclipseAdoptium.Temurin.8.JDK.x86 + EclipseAdoptium.Temurin.8.JDK.x64), WinGet will always select the best matched installer in the manifests based on the system architecture instead of the installed program architecture during upgrading. Maybe WinGet should remember the architecture the user specified in winget install?