Thank you both for valuable feedback,

Yes, this was very straight-forward fix, but also the less harmful. I tested it quite heavvily, and it does not move failure to "just later". Jre is working pretty find (as all calls to FontManagerFactory are returning this stub, which is making its job quite fine:) This fix was really intended for small (but maybe bigger then we think) group of headless devices, where openjdk have its place. Such a device can have pretty good output eg via html, but no need for fonts at "server" at all. This headless device will definitely have no need for fonts at all.
Except eg generating captcha which can be exactly the usage you have described.

However your contra-usecase with misconfigured system or JRE is more then true, and I agree with it. The workaround for user, to provide his ttf as default font can be maybe best solution.

The approach of OracleJDK is well known to me - It have its default fonts. In world of opensource the fonts were always little bit painful topic, but still this solution may be working to.

Anyway both solution above are workarounds and does not fix the issue that createFont(or even most of jre) should work no meter what fonts are installed.


Another suggested patch was make it configurable - but then it already is, as one can easily provide custom font manager via sun.font.fontmanager property. Then we can maybe make life little bit more easier by adding such "improved" fontmanager implementation.


I'm sorry for providing just linux implementation, but linux is probably target platform in such a devices. It was also serving as proof of concept. I'm definitely going to implement this also for win/mac when possible solution will be clarified.

Currently I'm definitely for adding NoFontsFound exception (better then NullPointException, and maybe extend it also for case that this Array have 0 length[just idea during writing]?), and think little bit more about it. Although I still like "my approach" the most, I'm going to obey yours advice but I still believe this issue is worthy to be fixed.

Best regards,
  J.


2012/11/12 Phil Race <philip.r...@oracle.com <mailto:philip.r...@oracle.com>>

    Well this seems like a really narrow use case for an extremely rare system
    misconfiguration. It wouldn't help the 99.999% of apps which expect to
    kick off AWT or Swing.

    And can you ensure that nothing in the app, or in the implementation makes
    the (reasonable) expectation that there are other fonts installed ?
    The most you could do is render to a BufferedImage or similar using the 
explicitly
    loaded font. The default logical font installed on a SG2D will be backed by 
a non-existent
    physical font, so you'd need to swap that in sooner rather than later.

    At some point you have to say that if JRE or system components are missing,
    then the source of the problem is what you should fix rather than make the
    JRE work around it.

    If you do want to try something, then in this case you get a much more 
usable
    runtime by providing a default font that the JRE can ensure is available so
    that the other 99.999% of apps can get by.

    The "Oracle" JDK gets by in this case precisely because it has a real 
physical font
    to fall back on.

    -phil.



Hi Phil,

I'm thinking here of Headless or embedded devices where the full Swing/AWT 
support may not be needed.

Anyway, I see your point that those cases are definitely the minority and if 
OpenJDK doesn't want to
work on those system, then I can only say that whoever is going to have such 
use case can just apply
this patch and live with it.

I totally agree however that if this comes from a misconfiguration rather than 
a conscious decision
the JDK should probably protect itself by failing earlier (it will fail anyway, 
as you noted though).

Perhaps a better patch would be to allow this to be configurable, by still 
introducing this new
FontManager but making it a named class and allow this as an option, defaulting 
on the old
behaviour, and at the same time giving a better error message.

Also, like you suggest, ship a fallback in jre/lib/fonts sound a better idea in 
most cases.

Cheers,
Mario

    On 11/12/2012 12:29 PM, Mario Torre wrote:

        Hi Phil,

        I believe that the underlying problem here is that it should be legal 
to create a font from
        a file, even if the FontManager doesn't have any fonts installed.

        So, code like the one in the example:
        public class Test {
              public static void main(String[] args) throws Exception {
                  Font.createFont(Font.TRUETYPE___FONT, new 
File("example.ttf"));
              }
        }

        When passed a real, valid font (example.ttf in this case) would still 
fail with the old
        code, and instead would work with the given patch (at least, I think 
this is the idea here,
        Jiri can probably explain in more details his intentions?).

        Cheers,
        Mario


        2012/11/12 Phil Race <philip.r...@oracle.com 
<mailto:philip.r...@oracle.com>
        <mailto:philip.r...@oracle.com <mailto:philip.r...@oracle.com>__>>


             Hello Jiri,

             Doesn't this just move the point of failure to a bit later ?
             I can't see how having zero fonts on the system is survivable for 
an
             app that uses fonts. That's the principal reason we haven't tried
             to do something like this already.

             When facing system configuration issues maybe we just need to
             print a better message for the exception such as
             throw new InternalError("Can't find any fonts installed on this
             system.");

             Or make the default font more configurable and distros could ship
             one in jre/lib/fonts.

             BTW it appears you are only trying to solve the problem for
             Linux/Unix.
             Nothing for Windows or OS X.

             -phil.


             On 11/12/2012 10:07 AM, Jiri Vanek wrote:

                 Hi!

                 This is attempt to fix
        https://bugzilla.redhat.com/__show_bug.cgi?id=862355
        <https://bugzilla.redhat.com/show_bug.cgi?id=862355>
                 The patch is introducing new exception
                 src/share/classes/sun/font/__NoFontsFoundException.java, which
                 is thrown from
                 /src/solaris/classes/sun/awt/__X11FontManager.java    instead 
of
                 null pointer exception when no fonts are found on system.
                 Exception is then catch in
                 src/share/classes/sun/font/__FontManagerFactory.java, and in
                 this case it returns (and not caching the instance of it)
                 dummy font manager instead of continue in failure.
                 the dummy manager do nothing, except that it is able to create
                 java.awt.Font in same way as SunFontManager is doing, but is
                 not doing any caching.

                 To avoid duplicate code with
                 src/share/classes/sun/font/__SunFontManager.java, i have
                 extracted code from method createFont2D to new method here -
                 prepareFont2D - which is responsible for creating font until
                 caching..

                 Best regards,
                   J.

                 webrev
        http://jvanek.fedorapeople.__org/oracle/jdk8/webrevs/__fontProperties/
        <http://jvanek.fedorapeople.org/oracle/jdk8/webrevs/fontProperties/>
                 with test  (although it will probably need some tuning and I'm
                 not sure where is the best place for it)
        
http://jvanek.fedorapeople.__org/oracle/jdk8/webrevs/__fontProperties/test/src/__nofontsreproducer/
        
<http://jvanek.fedorapeople.org/oracle/jdk8/webrevs/fontProperties/test/src/nofontsreproducer/>






        --
        pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
        Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

        IcedRobot: www.icedrobot.org <http://www.icedrobot.org> 
<http://www.icedrobot.org>

        Proud GNU Classpath developer: http://www.classpath.org/
        Read About us at: http://planet.classpath.org
        OpenJDK: http://openjdk.java.net/__projects/caciocavallo/
        <http://openjdk.java.net/projects/caciocavallo/>

        Please, support open standards:
        http://endsoftpatents.org/





--
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

IcedRobot: www.icedrobot.org <http://www.icedrobot.org>
Proud GNU Classpath developer: http://www.classpath.org/
Read About us at: http://planet.classpath.org
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Reply via email to