<div dir="ltr">I don't have enough of an understanding of the issues to say that this configuration should necessarily be supported.  However, I am relatively sure that it shouldn't be supported just enough to make the error and the code confusing.  If it doesn't find any fonts, FontConfigManager logs something to the platform logger and returns quietly.<br>

<br><div>      213         if (anyFont == null) {<br>      214             if (FontUtilities.isLogging()) {<br>      215                 PlatformLogger logger = FontUtilities.getLogger();<br>      216                 <a href="http://logger.info">logger.info</a>("Fontconfig returned no fonts at all.");<br>

      217             }<br>      218             fontConfigFailed = true;<br>      219             return;<br><br>and then when the X11FontManager "believes" it doesn't find a default font, it does a fallback:<br>

<br>      787         /* Absolute last ditch attempt in the face of fontconfig problems.<br>      788          * If we didn't match, pick the first, or just make something<br>      789          * up so we don't NPE.<br>

      790          */<br>      791         if (info[0] == null) {<br>      792             if (fontConfigFonts.length > 0 &&<br>      793                 fontConfigFonts[0].firstFont.fontFile != null) {<br>      794                 info[0] = fontConfigFonts[0].firstFont.familyName;<br>

      795                 info[1] = fontConfigFonts[0].firstFont.fontFile;<br>      796             } else {<br>      797                 info[0] = "Dialog";<br>      798                 info[1] = "/dialog.ttf";<br>

      799             }<br>      800         }</div><div><br></div><div style>That would make the casual reader believe that "no fonts" is a supported configuration (or, at least, a configuration that isn't supposed to NPE).  But the fallback doesn't get hit in this case, because the X11FontManager believes that getFontConfigFonts can't return null.  </div>

<div style><br></div><div style>It seems reasonable to throw an exception, if that's what you want to do, but it seems to me that the exception should have a relatively clear message about what happened, and the fact that that configuration is unsupported.  If you really want not to have code that deals with a lack of fonts, it would make a certain amount of sense to take out the code that is there and tries to do so.  As it is, the code and its behavior occupy a very confusing middle ground, where the developer has to trace through the library to figure out what happened and why it happened.</div>

<div style><br></div><div style>(As for not linking with libfontconfig: we're trying to make a JDK that works regardless of whether fontconfig is there.  It should be able to work in headless, stripped down mode, and for a developer who wants to use eclipse.  I don't mind if devs need to catch exceptions on the headless machines, but they like to know why they are catching them.)</div>

<div style><br></div><div style>Jeremy</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 5, 2013 at 1:56 AM, Jiri Vanek <span dir="ltr"><<a href="mailto:jvanek@redhat.com" target="_blank">jvanek@redhat.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<br>
<br>
<br>
This is known issue - Openjdk fails when no fonts are installed.<br>
<br>
You can fix this by your own fontmanager (feel free to inspire at <a href="https://bugzilla.redhat.com/show_bug.cgi?id=862355#c5" target="_blank">https://bugzilla.redhat.com/<u></u>show_bug.cgi?id=862355#c5</a> where I'm creating an custom dummy fontmanager in case of failure)<br>


You can set up similar manager class by -Dsun.font.fontmanager property.<br>
<br>
Or you can support me and "force somebody" to review my patch where I have tried to smuggle inside Openjdk default fallback font[1]<br>
<br>
On the contrary, if [1] will go in, then it can mask deeper problems (as can be eg yours).<br>
<br>
<br>
<br>
[1]<a href="http://mail.openjdk.java.net/pipermail/2d-dev/2013-January/002999.html" target="_blank">http://mail.openjdk.java.<u></u>net/pipermail/2d-dev/2013-<u></u>January/002999.html</a><br>
<br>
<br>
Best regards<br>
 J.<div><div class="h5"><br>
<br>
<br>
On 06/05/2013 01:32 AM, Jeremy Manson wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Hi Phil,<br>
<br>
Thanks for the response.  You've actually caught me out: this was a bug I found a while ago, and am<br>
only now just getting around to reporting.  I made this change locally (inside Google), and lost my<br>
repro instructions.  It was probably for a user issue, which means that I'm too chicken to back it<br>
out and see what happens.  This fix looked obvious enough that I thought I could get away with it,<br>
since it is clearly the case that X11FontManager expects a non-null fontConfigFonts regardless of<br>
the value of fontConfigFailed.<br>
<br>
IIRC, the cause was either that the fontconfig library wasn't installed or that the fontconfig file<br>
was obsolete / incorrect for the given system.  I almost certainly did not fix any ULEs (I would<br>
have a record of that).  We have some stripped down systems, and this may have been one of them.  It<br>
was a headless configuration.  I did preserve my stack trace:<br>
<br>
Exception in thread "main" java.lang.NullPointerException at<br>
sun.awt.X11FontManager.<u></u>getDefaultPlatformFont(<u></u>X11FontManager.java:779) at<br>
sun.font.SunFontManager$2.run(<u></u>SunFontManager.java:428) at<br>
java.security.<u></u>AccessController.doPrivileged(<u></u>Native Method) at<br>
sun.font.SunFontManager.<init><u></u>(SunFontManager.java:371) at<br>
sun.awt.X11FontManager.<init>(<u></u>X11FontManager.java:32) at<br>
sun.reflect.<u></u>NativeConstructorAccessorImpl.<u></u>newInstance0(Native Method) at<br>
sun.reflect.<u></u>NativeConstructorAccessorImpl.<u></u>newInstance(<u></u>NativeConstructorAccessorImpl.<u></u>java:57) at<br>
sun.reflect.<u></u>DelegatingConstructorAccessorI<u></u>mpl.newInstance(<u></u>DelegatingConstructorAccessorI<u></u>mpl.java:45)<br>
at java.lang.reflect.Constructor.<u></u>newInstance(Constructor.java:<u></u>530) at<br>
java.lang.Class.newInstance0(<u></u>Class.java:372) at java.lang.Class.newInstance(<u></u>Class.java:325) at<br>
sun.font.FontManagerFactory$1.<u></u>run(FontManagerFactory.java:<u></u>80) at<br>
java.security.<u></u>AccessController.doPrivileged(<u></u>Native Method) at<br>
sun.font.FontManagerFactory.<u></u>getInstance(<u></u>FontManagerFactory.java:71) at<br>
sun.java2d.<u></u>SunGraphicsEnvironment.<u></u>getFontManagerForSGE(<u></u>SunGraphicsEnvironment.java:<u></u>185) at<br>
sun.java2d.<u></u>SunGraphicsEnvironment.<u></u>getAllFonts(<u></u>SunGraphicsEnvironment.java:<u></u>192) at<br>
sun.java2d.<u></u>HeadlessGraphicsEnvironment.<u></u>getAllFonts(<u></u>HeadlessGraphicsEnvironment.<u></u>java:91)<br>
<br>
I'm sure that the line numbers are obsolete, but you get the general idea. I don't seem to have what<br>
was beneath that in the stack, but I imagine it was something that was relatively comfortable with<br>
getAllFonts returning nothing (as appropriate).<br>
<br>
Having said all that, it seems to me that if fontConfigFailed is not allowed to be true unless you<br>
have a system configuration problem, then that should be made clear at runtime, and that you should<br>
not get rather mysterious NPEs at later points in the code.  You do have a fallback in<br>
getDefaultPlatformFont that says "make something up so that we don't get NPE", which made me think<br>
that the original author intended to prefer avoiding NPEs.<br>
<br>
Jeremy<br>
<br>
<br></div></div>
On Tue, Jun 4, 2013 at 3:29 PM, Phil Race <<a href="mailto:philip.race@oracle.com" target="_blank">philip.race@oracle.com</a> <mailto:<a href="mailto:philip.race@oracle.com" target="_blank">philip.race@oracle.com</a><u></u>>><div class="im">

<br>
wrote:<br>
<br>
    Jeremy,<br>
<br>
    Why didn't it return any fonts ? Is this because the libfontconfig library isn't installed ?<br>
<br>
    We've been runtime loading that lib but these days could potentially<br>
    switch to linking against it at compile time, in which case you won't<br>
    even get this far. So in other words this could be a system config issue.<br>
    The most common thing I've seen is that 64 bit Linux doesn't have<br>
    all the libs to run a 32 bit JRE. You probably found and fixed all of those<br>
    because it was Unsatisfiedlinkerror or similar but the runtime linking<br>
    is disguising that its really the same problem.<br>
<br>
    If you really don't have any fonts installed, then that's also<br>
    a missing package and we perhaps should have a better diagnostic,<br>
    but there isn't really any point in continuing anyway without any fonts.<br>
    Even headless applications may require fonts.<br>
<br>
    -phil.<br>
<br>
<br>
    On 6/4/2013 2:50 PM, Jeremy Manson wrote:<br>
<br>
        Hi folks,<br>
<br>
        I encountered a NullPointerException in the above method, when fontconfig doesn't return any<br>
        fonts:<br>
<br></div>
        <a href="http://hg.openjdk.java.net/__jdk8/jdk8/jdk/file/__7eae7c89dab4/src/solaris/__classes/sun/awt/__X11FontManager.java" target="_blank">http://hg.openjdk.java.net/__<u></u>jdk8/jdk8/jdk/file/__<u></u>7eae7c89dab4/src/solaris/__<u></u>classes/sun/awt/__<u></u>X11FontManager.java</a><div class="im">

<br>
        <<a href="http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/7eae7c89dab4/src/solaris/classes/sun/awt/X11FontManager.java" target="_blank">http://hg.openjdk.java.net/<u></u>jdk8/jdk8/jdk/file/<u></u>7eae7c89dab4/src/solaris/<u></u>classes/sun/awt/<u></u>X11FontManager.java</a>><br>


<br>
        Line 779.  The issue is that FontConfigManager sets fontConfigFonts to null when Fontconfig<br>
        doesn't return any fonts:<br>
<br></div>
        <a href="http://hg.openjdk.java.net/__jdk8/jdk8/jdk/file/__7eae7c89dab4/src/solaris/__classes/sun/font/__FontConfigManager.java" target="_blank">http://hg.openjdk.java.net/__<u></u>jdk8/jdk8/jdk/file/__<u></u>7eae7c89dab4/src/solaris/__<u></u>classes/sun/font/__<u></u>FontConfigManager.java</a><div class="im">

<br>
        <<a href="http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/7eae7c89dab4/src/solaris/classes/sun/font/FontConfigManager.java" target="_blank">http://hg.openjdk.java.net/<u></u>jdk8/jdk8/jdk/file/<u></u>7eae7c89dab4/src/solaris/<u></u>classes/sun/font/<u></u>FontConfigManager.java</a>><br>


<br>
        Line 218.<br>
<br>
        The solution I came up with is to initialize fontConfigFonts with a zero-element array in<br>
        this case:<br>
<br></div>
        diff --git a/src/solaris/classes/sun/__<u></u>font/FontConfigManager.java<br>
        b/src/solaris/classes/sun/__<u></u>font/FontConfigManager.java<br>
        --- a/src/solaris/classes/sun/__<u></u>font/FontConfigManager.java<br>
        +++ b/src/solaris/classes/sun/__<u></u>font/FontConfigManager.java<br>
        @@ -216,6 +216,7 @@<br>
        <a href="http://logger.info" target="_blank">logger.info</a> <<a href="http://logger.info" target="_blank">http://logger.info</a>> <<a href="http://logger.info" target="_blank">http://logger.info</a>>("__<u></u>Fontconfig returned no fonts at all.");<div class="im">

<br>
<br>
                      }<br>
                      fontConfigFailed = true;<br>
        +            fontConfigFonts = new FcCompFont[0];<br>
                      return;<br>
                  } else if (fontConfigFailed) {<br>
                      for (int i = 0; i< fontArr.length; i++) {<br>
<br>
        Thanks for your attention!<br>
<br>
        Jeremy<br>
<br>
<br>
<br>
</div></blockquote>
<br>
</blockquote></div><br></div>