Bug 862355
| Summary: | The method Font.createFont() fails if no fonts are installed | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Juan Hernández <juan.hernandez> | ||||
| Component: | java-1.7.0-openjdk | Assignee: | jiri vanek <jvanek> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | BaseOS QE - Apps <qe-baseos-apps> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 6.3 | CC: | acavalla, ahughes, aph, dbhole, jvanek | ||||
| Target Milestone: | rc | Flags: | jvanek:
needinfo+
|
||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2015-09-18 13:56:06 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 861077, 1002711 | ||||||
| Attachments: |
|
||||||
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. 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...
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? 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? 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. (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. 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. Jiri, was a resolution ever reached on this? Do we depend on a font now? 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. Can we not make the RPMs depend on a font, such as dejavu-sans-fonts as listed in comment #1? 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. You haven't answered the question. 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? 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. 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. I don't see that happening any time soon, especially when Oracle ship their JDK with a font. So actually the assigment of this bug changes to: "find/create/prepare/ some font which will not take rest of X as dependence" |
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).