On 07/22/16 05:59 PM, Phil Race wrote:
Hi,
That looks reasonable .. but before an OK I would like to see the
results of running the test case in
the bug report after that fix. Run the test case with
-Dsun.java2d.debugfonts=true so we can see
what the JDK is doing internally. You can add the log to the bug report.
Thanks, I have attached the output of this to the bug.
Basically fontconfig is also likely to be subsequently invoked to build
the list of real fonts underlying
the logical font names (eg JDK sansserif which is the equivalent of
fontconfig's sans).
I suspect they will all end up just falling back to the Lucida Sans
Regular font shipped with JDK.
But for OpenJDK that won't be there .. so you may also want to see what
happens if you
then delete (move elsewhere) that font from jdk/lib/fonts. Maybe not a
VM crash but a Java NPE perhaps
as no fonts at all is not a supportable configuration.
Yes, you get a NPE.
# java Family
Exception in thread "main" java.lang.NullPointerException
at
sun.awt.FcFontManager.getDefaultPlatformFont(java.desktop@9-internal/FcFontManager.java:76)
at
sun.font.SunFontManager$2.run(java.desktop@9-internal/SunFontManager.java:434)
at
java.security.AccessController.doPrivileged(java.base@9-internal/Native
Method)
at
sun.font.SunFontManager.<init>(java.desktop@9-internal/SunFontManager.java:377)
at
sun.awt.FcFontManager.<init>(java.desktop@9-internal/FcFontManager.java:35)
at
sun.awt.X11FontManager.<init>(java.desktop@9-internal/X11FontManager.java:56)
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(java.base@9-internal/Native
Method)
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(java.base@9-internal/NativeConstructorAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(java.base@9-internal/DelegatingConstructorAccessorImpl.java:45)
at
java.lang.reflect.Constructor.newInstance(java.base@9-internal/Constructor.java:453)
at java.lang.Class.newInstance(java.base@9-internal/Class.java:569)
at
sun.font.FontManagerFactory$1.run(java.desktop@9-internal/FontManagerFactory.java:83)
at
java.security.AccessController.doPrivileged(java.base@9-internal/Native
Method)
at
sun.font.FontManagerFactory.getInstance(java.desktop@9-internal/FontManagerFactory.java:74)
at
sun.java2d.SunGraphicsEnvironment.getFontManagerForSGE(java.desktop@9-internal/SunGraphicsEnvironment.java:203)
at
sun.java2d.SunGraphicsEnvironment.getAllFonts(java.desktop@9-internal/SunGraphicsEnvironment.java:222)
at
sun.java2d.HeadlessGraphicsEnvironment.getAllFonts(java.desktop@9-internal/HeadlessGraphicsEnvironment.java:72)
at Family.main(Family.java:7)
So yes, that does mean I think that although avoiding a crash is good,
running graphics tests on
a system that has no font is an unsupported and unsupportable
configuration.
Put another way Java even as *headless* has a *hard* requirement on the
fonts being installed
and Solaris 12 not installing any by default means it does not satisfy
the requirements of Java
and that decision should be revisited .. else (and I really, really,
mean this) we can't support Solaris 12.
Well with a minimal install, Java is not installed either. As far as I
can tell, the Java package manifest delivered to Solaris does not depend
on the font files. I just "pkg install jdk-8" and no font files came
with it. So perhaps the Java pkg manifests needs to depend on the
relevant font package so that fonts will be installed when Java is
installed.
However this does not support the scenario where a JDK tar file is
dropped onto the machine. I am not sure whether we want to support this
scenario, we can take this off list for further discussion.
Thanks,
Martin
-phil.
On 07/22/2016 06:54 AM, Martin Walsh wrote:
Hi,
Could I get a review for the simple fix for
https://bugs.openjdk.java.net/browse/JDK-8160664
A webrev of the change is available here:
http://cr.openjdk.java.net/~aivanov/martin.walsh/8160664/jdk9/webrev.00/
Thanks,
Martin
