[OpenJDK 2D-Dev] "java.lang.Error: Probable fatal error:No fontsfound" does notshow on 11

[Bernd Eckenfels]

Hello,

Philip Race wrote:
> This is getting into "why doesn't my app run if I remove
> things it needs to run ?" territory.

Yes and no, the errors are caused by missing dependency declarations in common OS as well as undocumented requirements – no file delete caused those errors.

> A headless environment does not mean that fonts aren't needed.
> Headless environments are used to do text rendering.

Agree.

> So whilst we could have a discussion about what form the error
> should take, at some point you should get an error.

But:

a) Different Java versions produce different types of throwables, Errors and Runtime exceptions.
b) There is no specification which one can be expected (and catching Throwable is Pretty ugly in Terms of not suppressing real VM Errors)
c) A NPE Looks like a condition which should not happen

> Silently returning from all text rendering related API calls
> without failing would be even worse.

Ok, I can understand that it is probably too late to change this API.

> If you don't want to do anything with rendering, why is any kind
> of toolkit (headless or otherwise) being loaded ?

I think JasperReport in that case _does_ want to render, but it uses user provided Fonts (it only merges the System font to make them available). But even if not, the component might also be deployed and crashes on initialization (which is certainly ugly but not uncommon in app servers).
 
> The native fontconfig library isn't a runtime linker dependency only
> because we started using it before it could be guaranteed available
> for all the distro versions we support.

At least Suse and Redhat do not define the dependency (which I understand is not a problem of OpenJDK upstream), but still a sign that the assumption could be documented a bit better.

> If we were doing this today we'd almost certainly link at compile time
> and then if you did not install it your binary would not even start - even in
> headless mode. 

That decision would be clearer if there would be no Elaborate configuration system working around it. Maybe a good candidate for removal?

> I say this not because it would somehow improve your situation, but
> to make clear that libfontconfig is not an optional library.

Well, if the moon is in the Right constellation it does works without. 

> So on Linux fonts need to be provided by at least one of :
> -  the system + located using libfontconfig
> - in the JRE lib/fonts folder
> - in one of several  unspecified system locations that are still searched by
>  the Code that pre-dates libfontconfig
> The 2nd + 3rd of these should be considered legacy.

I figured that out (but it would be better to actually have a Statement in that direction)

>The 2nd applied to Oracle JDK when we shipped fonts, but adding your own
>fonts there is no longer supported by Oracle JDK or OpenJDK.

Is there somewhere a deprecation notice?

> The only scenario I can think of that might get by is where the app
> is supplying fonts using Font.createFont() and *only* those are used / >needed
>I suspect that is a rare case and would help only a very specific controlled >application where you knew you used those fonts and no other fonts.

It is Pretty common on reporting Servers and other drawing-generating applications which don’t depend on System Fonts (but still want to enumerate them).

For initial installations I guess it wont be that critical, you install it, it does not work, you add Fonts, done. However it does break when „upgrading“ a Oracle JDK with OpenJDK – depending on the OS packages installed. (and some more weirdness like not having all known OS properties files in all variations of Java distributions (Zulu for example ships „Fedora“ but not „RedHat“ fontconfig properties)

I feel I am done reporting, let me break down the issues so you can decide if any Needs addressing:

a) The NullPointerException should probably be changed into an InternalError with helpful message
b) The reflective wrappers in later versions should be unwrapped to get the formerly clean Error from Java 8.
c) The Javadoc should Mention that you need to expect an error (and possibly how to catch it without swallowing other vmerrors)
d) Somewhere the preferred way to deal with fontfonfig should be documented (and distributions should be made aware).
e) If fontconfig properties should still be supported, provide a common set so that distributions which are for multiple OS have the Benefit of shared Knowledge.

Gruss
Bernd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20190304/bac4c459/attachment-0001.html>