Hi. Thanx for report.

This is very unexpected but obvious consequence of https://src.fedoraproject.org/rpms/java-latest-openjdk/c/e16ee29c24b7c3fd46e4b2dec01a57bb13b99c18?branch=rawhide (alternatives creation moved to posttrans)
Before this commit, there existed two alternatives in same family, and then when the older one was removed, the link remained in family. Now, the removal happens first, and thus the family is gone, and alternatives fall-back to "recomended" and reset to auto.

The workaround have to be added, that in posun, the family and auto/manual is stored, and after install, if the family matches isnstalled JDK, and was manual mode (to allow system jdk bump) it gets sllected again. Hopefully that will also restore manual.

thoughts?

Created attachment 1842748 [details]
possible solution 1

three testing packages included.
if update, then in postun it saves manual, own, selected masters
in posttrans, if above saved, the link is set

The postrans can not be moved to function same as postun, because of --slave enumeration.

hints welcomed. More testing ahead.

*** Bug 2007270 has been marked as a duplicate of this bug. ***

what about not touching it at all in case of update versus new install when the alternatives links are there?

(In reply to Harald Reindl from comment #6)
> what about not touching it at all in case of update versus new install when
> the alternatives links are there?

It would be awesome, but how would you do that? The links points to NVRA directory.  So unluckily the old have to be removed, and the new created.

i forgot the java version mess where i recently deleted a dozens of old and orphaned version folders below /usr/lib/jvm/

(In reply to Harald Reindl from comment #8)
> i forgot the java version mess where i recently deleted a dozens of old and
> orphaned version folders below /usr/lib/jvm/

That should no longer be truth. If you hit it again, please drop the bug.

btw, 1.8 is not eol. RH maintains it, and is as secure and as maintained as 11 an 17. including focus on jdk8 compatibility.

i talked about ZendStudio in context of EOL

Created attachment 1843717 [details]
possible solution 2

A bit improved version.
I made quite a few testing, and will now port it to the jdks.

Created attachment 1844459 [details]
possible solution 3

Minor improvement.  Jdk have two groups of families So made it parameter.
Am it now emebdeing in jdk latest.

which one is supposed to fix that issue?
these two packages updated a few days ago changed the default again to 11

java-1.8.0-openjdk-headless-1.8.0.322.b06-2.fc34.x86_64
java-1.8.0-openjdk-1.8.0.322.b06-2.fc34.x86_64

shouldn't we close bugreports when it's really fixced and confirmed?

Hi! My rush action. I fall sick jsut before I backported to 8. And the changeset  had to be backport to all jdks in fedora. I will do update fo 8 today

FEDORA-2022-cc11e95290 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2022-cc11e95290

FEDORA-2022-ef6f35c74d has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-ef6f35c74d

FEDORA-2022-54b06abc5d has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-54b06abc5d

FEDORA-2022-809b238f89 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-809b238f89

FEDORA-2022-06f4afbe06 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2022-06f4afbe06

FEDORA-2022-54b06abc5d has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-54b06abc5d`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-54b06abc5d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2022-ef6f35c74d has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-ef6f35c74d`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-ef6f35c74d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2022-809b238f89 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-809b238f89`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-809b238f89

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2022-cc11e95290 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-cc11e95290`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-cc11e95290

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2022-06f4afbe06 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-06f4afbe06`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-06f4afbe06

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2022-809b238f89 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2022-ef6f35c74d has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2022-cc11e95290 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2022-06f4afbe06 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2022-54b06abc5d has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.

I just ran into this on RHEL8.  For reference, for others who run into this and manage to find this bug, you can avoid losing the alternatives during the upgrade by running the following shell script fragment before the upgrade:
ALTS="$(LANG=en_US.UTF-8 alternatives --list)"
for VER in 8 11 ; do
  for NAME in \
   java jre_openjdk "jre_${VER}" "jre_${VER}_openjdk" \
   javac java_sdk_openjdk "java_sdk_$VER" "java_sdk_${VER}_openjdk"
  do
    if ALT="$(echo "$ALTS" | grep "^$NAME[[:space:]]\+manual[[:space:]].*java-$VER-openjdk")" ; then
      ARCH="$(echo "$ALT" | perl -n -e 'print $1 if m!java-'"$VER"'-openjdk[^/]*\.([^/]+)/!')"
      touch "/var/lib/rpm-state/${NAME}_java-$VER-openjdk.$ARCH"
    fi
  done
  for NAME in javadocdir javadoczip ; do
    if ALT="$(echo "$ALTS" | grep "^$NAME[[:space:]]\+manual[[:space:]].*java-$VER-openjdk")" ; then
      touch "/var/lib/rpm-state/${NAME}_java-$VER-openjdk"
    fi
  done
done

Unfortunately, if you do not run the above before the upgrade then your alternatives will be lost and you will need to manually reconfigure them after the upgrade.

For jiri vanek:
While looking into this issue and developing the above shell script fragment, I noticed that the save_alternatives script fragment in the spec file does not check the arch of the current alternative before saving the state file, although the set_if_needed_alternatives script fragment does check the arch (indirectly via $FAMILY) when reading the state file.

I know that RHEL8 does not currently support multiarch Java so this is currently irrelevant.  However, if support for multiarch Java is brought back at some point, then this spec file will not properly preserve the correct arch on the java alternatives.  For example, if the alternative is currently using the i686 arch, and java is upgraded, and the %posttrans for the x86_64 version of java runs after the %posttrans for the i686 version of java, then the alternative will be switched from i686 to x86_64.

You might want to adjust save_alternatives() to also grep for the relevant arch in the alternatives config before writing the state file, to ensure that the correct arch is preserved if multiarch Java is installed.