Historically the Linux font code on start up looks for /etc/*-release files to determine the font.properties file to use.
These were names like redhat-release, SuSE-release, turbolinux-release

The fontconfig lookup uses both a name and a version.
The name mapping is hard-coded in the source code and is like this
/etc/redhat-release -> RedHat
/etc/fedora-release -> Fedora
/etc/turbolinux-release -> Turbo
/etc/SuSE-release -> SuSE

This font code also looks for /etc/lsb-release - because Ubuntu uses that and there's no /etc/ubuntu-release
or at least has not been for a very long time.
DISTRIB_ID and DISTRIB_RELEASE are the fields it locates there.

Then 8278549 added support for os-release since SUSE 15 dropped support for the SuSE-release file
and adopted the new /etc/os-release, which should now be used on all Linux distros

The fields NAME and ID are both candidates for the distro name, and VERSION_ID can be used for version number.
The SuSE fix looked for the NAME being SLES but then for compatibility with the names of config files
being shipped for various distros.

These mapped strings are used in the fontconfig file names.
The version is parsed out of the single line in each of these file.
If a fontconfig file specific to the distro and version can be found, it is used to construct logical font mappings.
eg we might look for fontconfig.RedHat.9.4.properties
There's more to it than just that file - pre-compiled versions, most-specific to least specific look ups but
that's the main idea.
It can fall all the way back to fontconfig.properties which has no distro and that only makes
sense if the JDK ships fonts which are used there. But the GPL version has never done so.

And maintaining these files was painful, so since JDK 7 the JDK dynamically builds what it wants to use
by asking the native libfontconfig for what the desktop uses.
The names obtained from the parsing logic are then used only to name a saved cached version of this in
~/.java/fonts to speed subsequent start-ups.

But we have kept the code to look up font properties files because some distros requested it so they could hand-craft files
to ship with the bundled version on the OS.

One problem with the look up of names like /etc/redhat-release is that there can be more than one such name.
Oracle Linux includes that /etc/redhat-release because it is derived from it but it also has /etc/oracle-release.
If both are present, which do you use ? Well currently we use /etc/redhat-release so OL is mis-identified as RHEL.
Since both will only be present on OL, a quick fix for that is to look for /etc/oracle-release first.

That would be a very compatible change.

However I am inclined to drop everything except parsing os-release.
This means it is very likely that the names of the hand-crafted files would need to change.
Eg from what I read "RedHat" would have to become "rhel" if we used the ID field and
"Red_Hat_Enterprise_Linux" if we used the NAME field - the code replaces spaces with _

I am inclined to using "ID". It is meant for machines to read, does not have to be reader friendly like a full name.

Because almost no one actually ships such files, the impact would be very limited.
And it would be MUCH easier to explain the names needed which now you can tell only from the source.
Instead we can say it is fontconfig.$ID.$ID_VERSION.properties on all distros.
No need to inspect JDK source.
Any distro that ships JDK specific to that version - as they must do since you need to be in sync with the fonts on the OS -
can easily name the file to match.