Skip to content

Issue with in-place upgrade to the latest version #679

Open

Description

@metaad

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:

  1. Install prev version of any of the above JDKs
  2. Install latest over the n-1
  3. CHeck ARP

Expected behavior
Latest should have upgraded n-1

Screenshots, Logs etc

Image Image

Additional context

Activity

  1. metaad commented on Aug 25, 2026

    @metaad
    Author

    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

  2. jmjaffe37 commented on Aug 28, 2026

    @jmjaffe37

    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:

    1. Install the desired OpenJDK(s) via Winget (see here for quick instructions)
    2. 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

  3. jmjaffe37 commented on Aug 28, 2026

    @jmjaffe37

    Also, there are a few other documented instances of this issue going back a ways in time. See:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions