RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 862355 - The method Font.createFont() fails if no fonts are installed
Summary: The method Font.createFont() fails if no fonts are installed
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: java-1.7.0-openjdk
Version: 6.3
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: jiri vanek
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks: 861077 1002711
TreeView+ depends on / blocked
 
Reported: 2012-10-02 17:28 UTC by Juan Hernández
Modified: 2018-12-02 16:01 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-09-18 13:56:06 UTC
Target Upstream Version:
Embargoed:
jvanek: needinfo+

Attachments (Terms of Use)
First patch (12.51 KB, patch)
2012-10-30 12:58 UTC, jiri vanek 		no flags Details | Diff
View All

Description Juan Hernández 2012-10-02 17:28:18 UTC 
Description of problem:

The method java.awt.Font.createFont(...) throws NullPointerException if there are no packages containing fonts installed (the output of fc-list is empty).

Version-Release number of selected component (if applicable):

java-1.7.0-openjdk-1.7.0.5-2.2.1.el6_3.x86_64


How reproducible:

Always.


Steps to Reproduce:

1. Make sure that there are no font packages installed:

# yum remove fontpackages-filesystem

2. Check that there are no fonts available according to fontconfig:

# fc-list

This command should return nothing, indicating that there are no fonts installed.

3. Compile the following Java program:

import java.awt.*;
import java.io.*;

public class Test {
    public static void main(String[] args) throws Exception {
        Font.createFont(Font.TRUETYPE_FONT, new File("example.ttf"));
    }
}

4. Create a empty example.ttf file:

# touch example.ttf

(The content of the file is not relevant, the failure is exactly the same with a valid .ttf font file).

5. Run the Java program:

# java Test
  
Actual results:

Exception in thread "main" java.lang.NullPointerException
	at sun.awt.X11FontManager.getDefaultPlatformFont(X11FontManager.java:779)
	at sun.font.SunFontManager$2.run(SunFontManager.java:432)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.font.SunFontManager.<init>(SunFontManager.java:375)
	at sun.awt.X11FontManager.<init>(X11FontManager.java:32)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
	at java.lang.Class.newInstance0(Class.java:372)
	at java.lang.Class.newInstance(Class.java:325)
	at sun.font.FontManagerFactory$1.run(FontManagerFactory.java:83)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:74)
	at java.awt.Font.<init>(Font.java:613)
	at java.awt.Font.createFont(Font.java:1023)
	at Test.main(Test.java:7)

Expected results:

The program should run without exceptions.


Additional info:

The workaround is to install any font package, for example:

# yum install dejavu-sans-fonts

After that fc-list will detect the new fonts and the Java program will run correctly (if given a correct .ttf file).
Comment 4 jiri vanek 2012-10-15 13:02:11 UTC 
heads up - font-manager, as written in current openjdk, is not able to work without at least some font. To create font instance is necessary instance of fontmanager (eg because of caching, but not only because of it) . In proprietary jdk this  will never happen, because they are providing default font always together with their jdk - so there is always some default font.

One workaround is to provide custom fontmanager implementation:
 - add implementation to classpath
 - set -D property of sun.font.fontmanager to your class implementing fontmanager

Deeper fix of this will probably need serious work on font manager, but I will check little bit deeper.
Comment 5 jiri vanek 2012-10-30 12:58:21 UTC 
Created attachment 635563 [details]
First patch

If you are running your own compiled jdk, this patch will work for you. It can take eons before it reaches packages...
Comment 6 jiri vanek 2012-11-19 16:54:27 UTC 
There are some troubles to explain why such a fix is worthy. Do you mind to follow http://mail.openjdk.java.net/pipermail/2d-dev/2012-November/002843.html (and 5more messages in thread)  and possibly add to this bug  or to mailing-list explanation why such a fix can be useful?
Comment 7 Juan Hernández 2012-11-19 17:09:32 UTC 
Jiri, we actually found this issue in the oVirt system. We use Jasper reports as the report generation engine and it brings its own fonts as .ttf files inside its .jar files. It doesn't use the system provided fonts for anything. Without the fix we are forced to install some font packages just to avoid the exception, even if they are not used.

Does this help?
Comment 8 jiri vanek 2012-11-21 12:13:18 UTC 
Well there is question whether to install some default fonts is or is not better then to push patch to openjdk. Well, looks like Oracle's people do not want the fix. I will try some another approach.
Comment 9 Andrew Haley 2012-11-29 11:31:22 UTC 
See http://mail.openjdk.java.net/pipermail/2d-dev/2012-November/002869.html
Comment 10 jiri vanek 2012-11-29 11:37:13 UTC 
(In reply to comment #9)
> See http://mail.openjdk.java.net/pipermail/2d-dev/2012-November/002869.html

According to it, the fix will never pass to upstream. So the workaround  - to install any font - will have to be enough.
Comment 16 RHEL Program Management 2013-10-14 04:45:36 UTC 
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 18 Andrew John Hughes 2015-08-21 20:20:21 UTC 
Jiri, was a resolution ever reached on this? Do we depend on a font now?
Comment 19 jiri vanek 2015-08-24 09:16:16 UTC 
Hi Andrew.

The latest recommendations were to install any font in case of this bug appearing.
So "close workaround"  is best to do. Close cant fix probably is the way to go.
I did not see upstream changing mind in no forest.
Comment 20 Andrew John Hughes 2015-08-26 15:29:25 UTC 
Can we not make the RPMs depend on a font, such as dejavu-sans-fonts as listed in comment #1?
Comment 21 Chris Williams 2015-09-18 13:56:06 UTC 
This Bugzilla has been reviewed by Red Hat and is not planned on being addressed in Red Hat Enterprise Linux 6 and therefore will be closed. If this bug is critical to production systems, please contact your Red Hat support representative and provide sufficient business justification.
Comment 22 Andrew John Hughes 2015-10-14 14:09:19 UTC 
You haven't answered the question.
Comment 23 jiri vanek 2015-10-15 06:03:43 UTC 
Oh comment disappeared...?...

So  again - I'm against adding font dependency. Most people have some fonts installed so it works for them. And they dont wont another font installed. And if somebody run into this issue, he may install whatever he wonts. Or not?
Comment 24 Andrew John Hughes 2016-01-06 14:00:36 UTC 
By the same reasoning, if you choose a common enough font, most people won't even notice a difference as they'll already have that font package installed. But it solves the problem for the minority who encounter this problem.
Comment 25 jiri vanek 2016-01-06 15:10:45 UTC 
Still the same point - why to instal any font automatically, when people cna install any font at all?

Still best solution would be JDK working without them.
Comment 26 Andrew John Hughes 2016-01-06 16:43:35 UTC 
I don't see that happening any time soon, especially when Oracle ship their JDK with a font.
Comment 27 jiri vanek 2016-01-06 17:39:17 UTC 
So actually the assigment of this bug changes to:
"find/create/prepare/ some font which will not take rest of X as dependence"
Note You need to log in before you can comment on or make changes to this bug.