JDK-8357672 : Extreme font sizes can cause font substitution
  • Type: Bug
  • Component: client-libs
  • Affected Version: 23,24,25
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2025-05-23
  • Updated: 2025-08-07
  • Resolved: 2025-06-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 17 JDK 21 JDK 25
11.0.29-oracleFixed 17.0.17-oracleFixed 21.0.9-oracleFixed 25 b26Fixed
Related Reports
Relates :  
Description
When extreme font sizes are used - as is the case with the test java/awt/FontMetrics/ExtremeFontSize.java -
the code is supposed to use a null scaler *context* - so that the advances, glyphs etc are all zero-size.
And per the fix for https://bugs.openjdk.org/browse/JDK-8328896, it should not invalidate the scaler itself,
or mark the font bad.
And that fix did resolve that after using large sizes, subsequent calls to get metrics (etc) for the font are not zero

Yet when (on Linux) I turn on logging I see the font de-registered which was not the plan.
FileFontStrike constructor - line 196 - will call deRegisterBadFont if the returned scaler context is null.
I think that call should be removed.

In the native call, if a call to calloc() fails it also returns 0 (NULL) - but in that case it also calls invalidateJavaScaler()

That code has been there since 2007  .. when the FreetypeScaler.c was introduced.
And I think it is wrong. It probably never gets executed but it is not a reason to invalidate the whole scaler,
and it means that for the caller, one case it can keep using the font (simple null return) but in the other case
it can't.

Also the ExtremeFontSize.java test can be enhanced to cache and compate the results of the "before" and "after" metrics.
Currently the font is replaced, so they will likely differ and they should not.

Comments
Fix request [21u,17u] I backport this for parity with 21.0.9-oracle,17.0.17-oracle. Low risk, limited to font handling. Clean backport. Test passes and reproduces the bug. SAP nightly testing passed.
22-07-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk17u-dev/pull/3776 Date: 2025-07-20 20:39:32 +0000
20-07-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk21u-dev/pull/2002 Date: 2025-07-20 20:39:25 +0000
20-07-2025

Changeset: a4eb1519 Branch: master Author: Phil Race <prr@openjdk.org> Date: 2025-06-02 15:24:09 +0000 URL: https://git.openjdk.org/jdk/commit/a4eb15195ceeadf311fe81e622a54f4733b90df2
02-06-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/25511 Date: 2025-05-28 20:19:42 +0000
28-05-2025