Description of problem:

When JDK 11 and 17 are co-installed, in some circumstances removing 11 causes /usr/bin/java to be deleted, despite JDK 17 being installed.

Version-Release number of selected component (if applicable):

Epoch : 1
Version : 11.0.15.0.10
Release : 1.el9_0

How reproducible:

Always

Steps to Reproduce:
1. podman build -t test ./ (with this Dockerfile present in $PWD):

FROM registry.access.redhat.com/ubi9/ubi-minimal:latest
RUN microdnf install -y java-11-openjdk-headless java-17-openjdk-headless
RUN alternatives --set java java-17-openjdk.x86_64
RUN rpm -e java-11-openjdk-headless
RUN stat /usr/bin/java
RUN /usr/bin/java -version

Actual results:

...
Step 8/9 : RUN stat /usr/bin/java
---> Running in b794fe9f289d
stat: cannot statx '/usr/bin/java': No such file or directory
The command '/bin/sh -c stat /usr/bin/java' returned a non-zero code: 1

Note that at present if you comment out the "RUN alternatives..." line, which
results in /usr/bin/java being JDK11, the problem goes away.

Expected results:

Expected is /usr/bin/java to remain and for it to be pointing to JDK17.

Additional info:

I've filed this against JDK11 since I think it is provoked by the postinst for JDK11's RPMs, but the problem might exist in the other JDK's too, I have not tried all combinations.

Running "alternatives" at the end re-creates /usr/bin/java. We're going to add this to the list of post-inst steps for the UBI9 OpenJDK 17 containers as a workaround for the time being. Ideally we would not need to, but we already have post-inst steps to work around #2080229 so they can go together.