Generally the packaging guidelines update is included as part of the change process and a PR is provided for us to merge when the change is approved. I'm surprised that didn't happen here. In fact, I thought that this was a mandatory part of the change procedure.

Edit: In fact, it is mandatory. https://docs.fedoraproject.org/en-US/program_management/changes_policy/#_fedora_packaging_committee

Java Packaging Guidelines update is not strictly required for this change as it is implicitly covered in other parts, such as "Noarch with Unported Dependencies".
But since ExclusiveArch is going to be used for all (or almost all) Java packages, I thought it would be good to explicitly include this requirement (or strong suggestion) it in Java Packaging Guidelines, hence I created this FPC ticket.

Basically, something like this ↓ will become mandatory for most Java packages?

BuildArch:     noarch
ExclusiveArch: %{java_arches} noarch

Adding this as a special case of https://docs.fedoraproject.org/en-US/packaging-guidelines/#_arch_specific_runtime_and_build_time_dependencies to the Java packaging Guidelines seems like a good idea.

Basically, something like this ↓ will become mandatory for most Java packages?

Yes, this will be the most common case and can serve as example in the guidelines. Other variations should be allowed too for archful Java packages and for packages (both noarch and archful) with other unported dependencies besides OpenJDK (in that case the list of exclusive arches may need to be a subset of %{java_arches}).

In the "archful" case, that would just collapse to ExclusiveArch: %{java_arches}, right? And for the more complicated case of "set intersection between supported architectures" can just be left as an exercise for the reader ...

In the "archful" case, that would just collapse to ExclusiveArch: %{java_arches}, right?

In the "archful" case, that would just collapse to ExclusiveArch: %{java_arches}, right?

Yes, I think so.

And for the more complicated case of "set intersection between supported architectures" can just be left as an exercise for the reader ...

I agree. I meant that the wording should not strictly require either of 2 exact ExclusiveArch values (for noarch or archful case), but leave room for special cases.

should the time of origin (f37) be mentioned or was macro bacported to older versions?

The macro was backported. I believe it's functional in EPEL as well.

As for the backports, please be aware that the content may be different. Eg on older fedoras it will include arm32. Its content should be always consulted with really built architectures of system JDK in given os.

Yes, The backports basically list all the available architectures. They only exist so people could use the macro and build from their Fedora/EL developer machines and/or share a single spec across branches.

Thanks for reminding me, I had volunteered to document this ages ago:

https://pagure.io/packaging-committee/pull-request/1187

Please review the new Architecture support section for correctness. The other changes are only minor fixes for formatting or bad grammar.

My PR has been merged. I think we can close this issue?

Seems like it.