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