You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Issue with in-place upgrade to the latest version #679
Describe the bug
We are 3rd party patch provider like PatchMyPC or ManageEngine. We are providing similar services to our customers. For more details you may refer https://adaptiva.com/products/autonomous-patch.
We are currently evaluating OpenJDK v11 v21 v25 v17 latest installer , however while upgrading we found the the both version co-exist (eg-- upgrading from previous version i.e, v11.0.32 to v11.0.32.1)
Desktop (please complete the following information):
Tested on Win11 and Win10 VM
OS & version [e.g. Windows 10, 1822]:
for win11
Edition Windows 11 Enterprise
Version 24H2
Installed on 4/5/2026
OS build 26100.4349
Experience Windows Feature Experience Pack 1000.26100.107.0
for win 10
Edition Windows 10 Enterprise
Version 22H2
Installed on 05/04/2026
OS Build 19045.6456
MSFT Build of OpenJDK Version:
V11 -- 11.0.32.1
v21 -- 21.0.12.1
v25 -- 25.0.4.1
v17-- 17.0.20.1
The output from java --version
same as latest To Reproduce:
Steps to reproduce the behavior:
Does this means that the bug is going to be resolved or it is stating that for v17.0.20.8 the version has changed to 17.0.20.101 but the package remains the same -- as the issue discribed above is not resolved
metaad, I was able to repro the issue. In my testing, this issue only appears if one is using our legacy MSI installer. This happens due to the special versioning of August's build (which will now be a more frequent versioning scheme). This versioning actually clashes with a limitation of the MSI installer, where the MSI installer can only consider the first 3 numbers in a product version when determining an upgrade (see our installer creation README.ME's upgrade details, or Microsoft's learn page which documents the limitation). You can also find Adoptium's explanation of the MSI limitation here.
Example: This means that the JDK11 upgrade 11.0.31+11 -> 11.0.32+9 works since 32 > 31, but the upgrade 11.0.32+9 -> 11.0.32.1+1 will not work since 32 == 32. Here, the MSI decides not to overwrite the older JDK version.
The recommended fix is to uninstall all JDK installations that were installed via the MSI installer, then do either of the following:
Install the desired OpenJDK(s) via Winget (see here for quick instructions)
Install the desired OpenJDK(s) via our new/supported exe installer (see here for instructions)
Both of these options will ensure that all upgrades are handled properly in the future, just make sure to keep using the same method going forward 🙂
Please let me know if you have any questions,
-Josh
Activity
metaad commentedon Aug 25, 2026
Does this means that the bug is going to be resolved or it is stating that for v17.0.20.8 the version has changed to 17.0.20.101 but the package remains the same -- as the issue discribed above is not resolved
jmjaffe37 commentedon Aug 28, 2026
metaad, I was able to repro the issue. In my testing, this issue only appears if one is using our legacy MSI installer. This happens due to the special versioning of August's build (which will now be a more frequent versioning scheme). This versioning actually clashes with a limitation of the MSI installer, where the MSI installer can only consider the first 3 numbers in a product version when determining an upgrade (see our installer creation README.ME's upgrade details, or Microsoft's learn page which documents the limitation). You can also find Adoptium's explanation of the MSI limitation here.
Example: This means that the JDK11 upgrade
11.0.31+11 -> 11.0.32+9works since32 > 31, but the upgrade11.0.32+9 -> 11.0.32.1+1will not work since32 == 32. Here, the MSI decides not to overwrite the older JDK version.The recommended fix is to uninstall all JDK installations that were installed via the MSI installer, then do either of the following:
Both of these options will ensure that all upgrades are handled properly in the future, just make sure to keep using the same method going forward 🙂
Please let me know if you have any questions,
-Josh
jmjaffe37 commentedon Aug 28, 2026
Also, there are a few other documented instances of this issue going back a ways in time. See: