RFR: 8370719: [Linux] Use /etc/os-release values for font configuration file names

Sergey Bylokhov serb at openjdk.org
Mon Nov 3 21:22:42 UTC 2025


On Thu, 30 Oct 2025 19:07:04 GMT, Phil Race <prr at openjdk.org> wrote:

> The JBS issue has a long discussion and explanation but here's a short version.
> Instead of having baked in names of distros in the code that figures out names for font configuration files for Linux
> use the standard ID and VERSION_ID fields in /etc/os-release which is now standard.
> even systemd doesn't work if it does not exist https://0pointer.de/blog/projects/os-release
> And if it doesn't we just use "Linux" as the name.

src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java line 320:

> 318:         }
> 319:         try {
> 320:             File f = new File("/etc/os-release");

Don't we need to check "/usr/lib/os-release" as well?
https://www.freedesktop.org/software/systemd/man/latest/os-release.html
>The file /etc/os-release takes precedence over /usr/lib/os-release. Applications should check for the former, and exclusively use its data if it exists, and only fall back to /usr/lib/os-release if that is missing. Applications should not combine the data from both files. /usr/lib/os-release is the recommended place to store OS release information as part of vendor trees. /etc/os-release should be a relative symlink to /usr/lib/os-release, to provide compatibility with applications only looking at /etc/. A relative symlink instead of an absolute symlink is necessary to avoid breaking the link in a chroot or initrd environment.

src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java line 321:

> 319:         try {
> 320:             File f = new File("/etc/os-release");
> 321:             if (f.canRead()) {

Should we check whether this is a file and not a directory?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28073#discussion_r2487878342
PR Review Comment: https://git.openjdk.org/jdk/pull/28073#discussion_r2487871539


More information about the client-libs-dev mailing list