Bug 862355 - The method Font.createFont() fails if no fonts are installed
Summary: The method Font.createFont() fails if no fonts are installed
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
Target Milestone: rc
: ---
Assignee: jiri vanek
QA Contact: BaseOS QE - Apps
Depends On:
Blocks: 1002711 861077
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:
Last Closed: 2015-09-18 13:56:06 UTC
Target Upstream Version:
jvanek: needinfo+

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

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):


How reproducible:


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 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.