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/
