Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

There was no fonts in Linux version #70

Closed
karianna opened this issue Oct 23, 2018 · 48 comments
Closed

There was no fonts in Linux version #70

karianna opened this issue Oct 23, 2018 · 48 comments
Assignees
Labels
bug Something isn't working wontfix This will not be worked on
Milestone

Comments

@karianna
Copy link
Contributor

From @JamesMung on October 23, 2018 3:54

JDK Version ; jdk8u181-b13

When I use jasper print PDF in Windows is fine, but for Linux found the error as follow:

Caused by: net.sf.jasperreports.engine.JRRuntimeException: java.io.IOException: Problem reading font data.
        at net.sf.jasperreports.engine.fonts.SimpleFontFace.<init>(SimpleFontFace.java:108)
        at net.sf.jasperreports.engine.fonts.SimpleFontFace.<init>(SimpleFontFace.java:128)
        at net.sf.jasperreports.engine.fonts.SimpleFontFace.getInstance(SimpleFontFace.java:67)
        at net.sf.jasperreports.engine.fonts.SimpleFontFamily.setNormal(SimpleFontFamily.java:99)
        at net.sf.jasperreports.engine.fonts.SimpleFontExtensionHelper.parseFontFamily(SimpleFontExtensionHelper.java:261)
        at net.sf.jasperreports.engine.fonts.SimpleFontExtensionHelper.parseFontFamilies(SimpleFontExtensionHelper.java:232)
        at net.sf.jasperreports.engine.fonts.SimpleFontExtensionHelper.loadFontFamilies(SimpleFontExtensionHelper.java:193)
        at net.sf.jasperreports.engine.fonts.SimpleFontExtensionHelper.loadFontFamilies(SimpleFontExtensionHelper.java:162)
        at net.sf.jasperreports.engine.fonts.FontExtensionsRegistry.getExtensions(FontExtensionsRegistry.java:56)
        at net.sf.jasperreports.extensions.DefaultExtensionsRegistry.getExtensions(DefaultExtensionsRegistry.java:110)
        at net.sf.jasperreports.engine.util.JRStyledTextParser.<clinit>(JRStyledTextParser.java:83)
        ... 73 more
Caused by: java.io.IOException: Problem reading font data.
        at java.awt.Font.createFont0(Font.java:1000)
        at java.awt.Font.createFont(Font.java:877)
        at net.sf.jasperreports.engine.fonts.SimpleFontFace.<init>(SimpleFontFace.java:100)
        ... 83 more

Can you help for solve this problem in current version ? And please fix it in future version.

Copied from original issue: AdoptOpenJDK/openjdk8-releases#16

@sxa
Copy link
Member

sxa commented Oct 23, 2018

HI @JamesMung - I haven't used jasper before - do you have a quick set of instructions to reproduce the error? Also which Linux distribution are you using (it's unclear if this is a JDK issue or something that's supposed to be on the underlying OS).

@JamesMung
Copy link

Hi @sxa555, I tried to use Oracle JDK of Linux version and it's no problem to print PDF. So I compare between Windows and Linux version. I found Windows version has fonts and config in jre directory. But I can't found it from Linux version. So I think this is the problem.

And I tried to copy the font and config from Oracle JDK to Adopt JDK. but it's not work. Can you kindly give the solution to solve it ? And please fix it in further versions.

Distribution : jdk8u181-b13 Linux x64

@xinyi9
Copy link

xinyi9 commented Oct 29, 2018

Hi there, our team hit this problem on various Linux distributions too. (Ubuntu, Centos, Debian etc)
JDK version: jdk8u181-b13

We hit this problem even at a very early phase, when installing our product using installer4j, stack trace as follows:

java.lang.NullPointerException at sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1264) at sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:219) at sun.awt.FontConfiguration.init(FontConfiguration.java:107) at sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:774) at sun.font.SunFontManager$2.run(SunFontManager.java:431) at java.security.AccessController.doPrivileged(Native Method) at sun.font.SunFontManager.<init>(SunFontManager.java:376) at sun.awt.FcFontManager.<init>(FcFontManager.java:35) at sun.awt.X11FontManager.<init>(X11FontManager.java:57) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:423) at java.lang.Class.newInstance(Class.java:442) at sun.font.FontManagerFactory$1.run(FontManagerFactory.java:83) at java.security.AccessController.doPrivileged(Native Method) at sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:74) at sun.font.SunFontManager.getInstance(SunFontManager.java:250) at sun.font.FontDesignMetrics.getMetrics(FontDesignMetrics.java:264) at sun.swing.SwingUtilities2.getFontMetrics(SwingUtilities2.java:1113) at javax.swing.JComponent.getFontMetrics(JComponent.java:1626) at javax.swing.text.WrappedPlainView.updateMetrics(WrappedPlainView.java:318) at javax.swing.text.WrappedPlainView.updateChildren(WrappedPlainView.java:297) at javax.swing.text.WrappedPlainView.insertUpdate(WrappedPlainView.java:463) at javax.swing.plaf.basic.BasicTextUI$RootView.insertUpdate(BasicTextUI.java:1610) at javax.swing.plaf.basic.BasicTextUI$UpdateHandler.insertUpdate(BasicTextUI.java:1869) at javax.swing.text.AbstractDocument.fireInsertUpdate(AbstractDocument.java:201) at javax.swing.text.AbstractDocument.handleInsertString(AbstractDocument.java:748) at javax.swing.text.AbstractDocument.insertString(AbstractDocument.java:707) at javax.swing.text.PlainDocument.insertString(PlainDocument.java:130) at javax.swing.text.DefaultEditorKit.read(DefaultEditorKit.java:273) at javax.swing.JEditorPane.setText(JEditorPane.java:1416) at javax.swing.JEditorPane.<init>(JEditorPane.java:290) at com.install4j.runtime.installer.frontend.headless.AbstractHeadlessScreenExecutor.init(AbstractHeadlessScreenExecutor.java:68) at com.install4j.runtime.installer.frontend.headless.ConsoleScreenExecutor.<init>(ConsoleScreenExecutor.java:24) at com.install4j.runtime.installer.frontend.headless.InstallerConsoleScreenExecutor.<init>(InstallerConsoleScreenExecutor.java:6) at com.install4j.runtime.installer.Installer.getScreenExecutor(Installer.java:88) at com.install4j.runtime.installer.Installer.runInProcess(Installer.java:57) at com.install4j.runtime.installer.Installer.main(Installer.java:45) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.exe4j.runtime.LauncherEngine.launch(LauncherEngine.java:85) at com.install4j.runtime.launcher.UnixLauncher.main(UnixLauncher.java:62)

Currently we use a workaround to install font dependency by
apt install fontconfig

However, this workaround will change behaviour when our customer switches from Oracle jdk to AdoptOpenJDK, and remains a compatibility issue for us.

Would the team consider bundle the font config in the JDK and help fix it in further versions?

Cheers,

Distribution : jdk8u181-b13 Linux x64

Moved this to a new issue as it seems different from the original issue adoptium/temurin-build#693

@JamesMung
Copy link

Hi @xinyi9, Thanks for your solution. BTW, @sxa555 I tried use these code in my program :

try {
	GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
	File fontsDir = new File(System.getProperty("user.home") + "/fonts"); // fonts dir (*.ttf)
	if(fontsDir.isDirectory()){
		for(File file : fontsDir.listFiles()){
			ge.registerFont(Font.createFont(Font.TRUETYPE_FONT, file));
					
			if(logger.isInfoEnabled()) {
				logger.info("Load font " + file.getName());
			}
		}
	}
} catch (Exception e) {
	e.printStackTrace();
}

And it appear NullPointerException same as @xinyi9 provided. I wish it would helpful for you.

Distribution : jdk8u181-b13 Linux x64

@enasser
Copy link

enasser commented Oct 29, 2018

The fonts in jre/lib/fonts directory are taken from closed code in Oracle JDK and missing from openJDK. We need to understand why it is failing only on Linux and not on Windows. Which fonts were trying to create when the failure occurred. @mbvreddy FYI

@karianna
Copy link
Contributor Author

This might be similar to the porting issue we have for cacerts. I think the correct thing to do is to propose a patch for upstream 8u to add these.

@jarnbjo
Copy link

jarnbjo commented Nov 19, 2018

Initially commented on issue 693, but also relevant here:

The NullPointerException in FontConfiguration.java:1264 is caused by a missing font configuration file, which is not included with the Linux version of AdoptOpenJDK. It is important to notice that the direct cause of the exception is a missing configuration file and not that actual font files are missing.

When the AWT font subsystem is initialized, it will look for a font configuration file in $JAVA_HOME/lib following a naming scheme and priority as described here: https://docs.oracle.com/javase/8/docs/technotes/guides/intl/fontconfig.html

Even if no fonts are provided by the JDK and use of OS provided fonts is not intented or configured, a minimal configuration is required by the AWT font subsystem to initialize without throwing exceptions. Providing a fontconfig.properties file in $JAVA_HOME/lib with the following two lines will at least, to start with, mitigate the problem with the NullPointerException:

version=1
sequence.allfonts=default

Since we are only using fonts bundled with our application, this is a feasible workaround in our situation. It allows the font subsystem to initialize and we can later without issues load our own fonts from the classpath. I am not sure what happens and YMMV if you try to run an application, which relies on the JDK to provide actual fonts, either as bundled with the JDK or as provided by the operating system.

mmuth referenced this issue in meisterplan/docker-openjdk-springboot Dec 5, 2018
- because adoptjdk currently leads to problems
  when generating excel files with apache POI
  (or when generating PDFs, also see
  https://github.com/AdoptOpenJDK/openjdk-build/issues/682)
xcq1 referenced this issue in meisterplan/docker-openjdk-springboot Dec 5, 2018
- because adoptjdk currently leads to problems
  when generating excel files with apache POI
  (or when generating PDFs, also see
  https://github.com/AdoptOpenJDK/openjdk-build/issues/682)
@jgha99user
Copy link

I also encountered this issue with jdk8u181-b13 on centos 7. I was not able to resolve the issue using this adoptopenjdk. I agree, it would be nice if future releases of adoptopenjdk has font support. Another option, outside java seems to be getting the fonts loaded directly to the linux OS (as the os is the fallback if fonts are not available in java). We didn't test this yet.

@jgkirschbaum
Copy link

Installing packages fontconfig and urw-fonts on CentOS 6 & 7 fixed the issue.

@smcilhinney
Copy link

smcilhinney commented Apr 10, 2019

Just to add to the list of people who have experienced this, I hit this issue when using Apache POI (which uses fonts in the background to size Excel columns etc) on a headless server. In essence jarnbjo is right - the cause of the exception shown in the issue is the lack of the fontconfig.properties file.

In my case this alone wasn't sufficient to remove the issue. For any task that needs an actual font to be present you need two things:

  1. The JDK/the system to have some way of finding fonts.
  2. At least one font to find - this is where I had additional problems.

No. 1 can be provided by the Java fontconfig.properties system, or (on Linux) by the fontconfig package - both seem to work. Solving no. 2 means actually having a font file somewhere that your solution to no. 1 can find it. Solution that worked for me (on Centos 6/7) was installing the fontconfig and liberation-sans-fonts packages (the choice of font is arbitrary, any worked, including manual installs).

Ideally (for my purposes) the JDK distribution would include the Java fontconfig.properties and at least one default font, just like the Sun distribution does (maybe some more open font to replace Lucidia if licensing is the issue). If that were the case then my code would run with Adopt OJDK out of the box, whereas at the moment there are "hidden" dependencies on bare-bones Linux distributions.

The upstream OpenJDK (as provided by the Centos repositories) solves this problem by introducing actual package dependencies on the extra packages needed, but that's probably not practical for Adopt OJDK.

Edit: 1.8.0_202-b08 was the version I tested.

Minimal code to reproduce:

import java.awt.*;

public class FontTest {

    public static void main(String[] args) {

        String[] names = GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames();

        System.out.println("Found " + names.length + " fonts:");

        for (String name : names) {

            System.out.println(name);
        }
    }
}

The above will fail at the getAvailableFontFamilyNames on a system without fontconfig, leading to the error posted by xinyi9.

@echua
Copy link

echua commented May 15, 2019

I was struggling with this until I downloaded Adopt JDK8 with the OpenJ9 JVM. The Hotspot version does not work and that solved my problems. I wasn't getting many errors at all so finally started from scratch and noticed this.

@maxpg
Copy link

maxpg commented May 24, 2019

Does anyone know the progress of this issue? I see in the migration guide that "Relicensed Lucidia Fonts" are "coming soon". It also states Q2 2019.

How is the progress on that? Is it planned to be part of the next Java 8 Update? Is there still potential to slip out of Q2 or is it basically already finished?

@karianna
Copy link
Contributor Author

@maxpg we have the May 2019 milestone label which means it's in the bucket of things that we want to look at next (May is false in terms of timing though). It's an unassigned issue so unless a volunteer picks it up beforehand we won't tackle it until some other priorities get sorted first.

@moschinski
Copy link

@karianna The issue is a major one if you want to ship your (on-premise) application with AdoptOpenJDK as the application may not work correctly on some Linux distributions. Considering this, I hope that you can give the issue a higher priority and a reliable milestone (waiting half a year because your page states "expected to complete in 2Q 2019" just to see that the issue is still unassigned is somewhat disappointing).

@karianna
Copy link
Contributor Author

@karianna The issue is a major one if you want to ship your (on-premise) application with AdoptOpenJDK as the application may not work correctly on some Linux distributions. Considering this, I hope that you can give the issue a higher priority and a reliable milestone (waiting half a year because your page states "expected to complete in 2Q 2019" just to see that the issue is still unassigned is somewhat disappointing).

We do our best to prioritize issues that impact the most folks, but this is a community/volunteer project. If you'd like this particular issue looked at more quickly then we're always looking for more help and/or there are support options listed at adoptopenjdk.net/support.html

@mduft
Copy link

mduft commented Aug 13, 2019

We're having issues here as well (on AdoptOpenJDK10):

Caused by: java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.GeneratedConstructorAccessor9.newInstance(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:488)
	at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:84)
	... 32 more
Caused by: java.lang.NullPointerException
	at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1288)
	at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:225)
	at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:107)
	at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:765)
	at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:440)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.desktop/sun.font.SunFontManager.<init>(SunFontManager.java:385)
	at java.desktop/sun.awt.FcFontManager.<init>(FcFontManager.java:35)
	at java.desktop/sun.awt.X11FontManager.<init>(X11FontManager.java:56)
	... 36 more

It happens for us on vanilla Fedora 30 (just boot the live CD). Whenever AWT or Swing is used, things go bad... I have no idea what the problem is, libfontconfig.so.1 is present, so I guess it must be something else...

I did test this with the reference build as well (https://jdk.java.net/java-se-ri/10), and this works. So it must be something with AdoptOpenJDK builds... but what?

@mduft
Copy link

mduft commented Aug 14, 2019

I upgraded to AdoptOpenJDK 11, and this fixed the issue for Fedora 30. I can confirm that fonts work out of the box where they did not with JDK10. We were unable to upgrad to 11 previously due to jersey not supporting it, but now it works :)

openjdk version "11.0.4" 2019-07-16
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.4+11)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.4+11, mixed mode)

@karianna
Copy link
Contributor Author

OK so it sounds like this is still an issue for AdoptOpenJDK 8 but not 11 (potentially)

@scoobsterscoobster
Copy link

scoobsterscoobster commented Aug 20, 2019

Adding this info in hopes it might help someone or provide some clues, although the exact scenario is a little different than above:

Context:
My application uses a PDF generation tool (Crystal Reports) to generate PDFs. This runs in a Windows 10 environment.

Short Story:
My issues go away when I create a JAVA_HOME/jre/lib/fonts and add ANY single ttf font that is installed on my system.

Long Story:
On Amazon Corretto 8 or AdoptOpenJDK 8, I get an NPE when Crystal Reports (thrown from its OpenTypeFontManager) is generating a PDF. Like many people, I tried copying Oracle's font folder to JAVA_HOME/jre/lib/fonts. In Corretto I get 'java.lang.UnsatisfiedLinkError: \jre\bin\fontmanager.dll: Can't find dependent libraries', and in AdoptOpenJDK the PDF would generate but with no text, and a few special symbols sprinkled on the page. On Corretto 11, there were no errors and the PDFs generated successfully.

I deleted the contents of the 'fonts' folder and copied a single TTF font (webdings.ttf, which is not even used by the PDF) and things worked in both Corretto and AdoptOpenJDK.

I then also added back all of the Oracle fonts (LucidaBrightDemiBold, LucidaBrightDemiItalic, LucidaBrightItalic, LucidaBrightRegular, LucidaSansDemiBold, LucidaTypewriterBold, LucidaTypewriterRegular, LucidaSansRegular) and things failed again. (All of these fonts were installed on the OS). I then deleted each Oracle font one by one until I discovered that deleting LucidaSansRegular alone was enough to make things work.

Summary:
Copying over the Oracle fonts and deleting LucidaSansRegular OR creating an empty 'fonts' directory and copying one of the OS fonts, made things work in Corretto and AdoptOpenJDK.

@theredcat
Copy link

theredcat commented Dec 27, 2019

Having this issue on Debian 10 while trying to run Jenkins 2.204.1 WAR with 11.0.5+10 JDK (I have not tested with the JRE)

Using JDK release : https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/download/jdk-11.0.5%2B10/OpenJDK11U-jdk_x64_linux_hotspot_11.0.5_10.tar.gz
Using Jenkins release : http://mirrors.jenkins.io/war-stable/2.204.1/jenkins.war

The @jarnbjo solution worked for me.

I use linux binaries and install them in /usr/share/java/{java_version}. Creating /usr/share/java/jdk-11.0.5+10/lib/fontconfig.properties with the following content allowed jenkins to start:

version=1
sequence.allfonts=default

@sxa
Copy link
Member

sxa commented Dec 31, 2019

@lumpfish is this related to what you were working on recently?

@lumpfish
Copy link

lumpfish commented Jan 6, 2020

Some of it, yes. I was looking for any progress on the The AdoptOpenJDK migration guide (https://adoptopenjdk.net/MigratingtoAdoptOpenJDKfromOracleJava.pdf) statement "The Lucida fonts that are available in Oracle JDK 8 have a proprietary 3rd party license. AdoptOpenJDK intends to provide relicensed Lucida fonts. Work is ongoing to minimize any display issues when these fonts are rendered by Freetype and are expected to complete in 2Q2019."
From this issue I deduce it is still unresolved.
What needs to be done to "provide relicensed Lucida fonts"?

@sxa sxa transferred this issue from adoptium/temurin-build Mar 3, 2020
@sidvar9
Copy link

sidvar9 commented Mar 3, 2020

We are also having the same issue and wondering where we are in providing the re-licensed Lucida fonts. Its mentioned in the AdoptOpenJDK migration guide that these will be available by Q2 2019. Or if there is a known workaround that we can use for now. Thanks!

@lumpfish
Copy link

lumpfish commented Mar 9, 2020

@karianna - is there a plan for resolving this? There are a number of AdoptOpenJDK users requesting these fonts and currently the AdoptOpenJDK position is that they are to be included in the AdoptOpenJDK builds.

I had interpreted the statement "The Lucida fonts that are available in Oracle JDK 8 have a proprietary 3rd party license. AdoptOpenJDK intends to provide relicensed Lucida fonts." to mean that the AdoptOpenJDK community would be seeking a license. Is that correct? If so when / how would that happen?

@sxa sxa added the TSC-Agenda label Mar 9, 2020
@aahlenst
Copy link
Contributor

aahlenst commented Mar 9, 2020

Would including DejaVu suffice? Should be easier to package because it is free.

@karianna
Copy link
Contributor Author

@karianna - is there a plan for resolving this? There are a number of AdoptOpenJDK users requesting these fonts and currently the AdoptOpenJDK position is that they are to be included in the AdoptOpenJDK builds.

I had interpreted the statement "The Lucida fonts that are available in Oracle JDK 8 have a proprietary 3rd party license. AdoptOpenJDK intends to provide relicensed Lucida fonts." to mean that the AdoptOpenJDK community would be seeking a license. Is that correct? If so when / how would that happen?

That's a potential path forward. I'm not sure if there's a an OSS replacement that has the same L&F

@karianna karianna modified the milestones: June 2020, July 2020 Jul 1, 2020
@karianna
Copy link
Contributor Author

karianna commented Jul 2, 2020

We see-sawed back and forth and we're back to providing a fontconfig.properties file to remove the NPE and maybe try to add a free font to remove one other class of problems.

@aahlenst
Copy link
Contributor

aahlenst commented Jul 2, 2020

@karianna To save you some time, https://dejavu-fonts.github.io/ is the home of the DejaVu fonts, https://dejavu-fonts.github.io/License.html is their license. The tarball of Azul Zulu contains some fontconfig.properties templates with appropriate mappings.

@madhu-broad
Copy link

#70 (comment)

AdoptOpenJDK/openjdk-support Getting NULL pointer exception at sun.awt.FcFontManager.getDefaultPlatformFont(FcFontManager.java:76)#80

To just to update, We had raised this issue on Solaris platform (both x86 and sparc). Hope the fix will work for Solaris installers and binaries too.

@karianna karianna modified the milestones: July 2020, August 2020 Aug 2, 2020
@karianna
Copy link
Contributor Author

karianna commented Aug 4, 2020

Also see adoptium/temurin-build#693

@karianna karianna modified the milestones: August 2020, September 2020 Sep 1, 2020
@madhu-broad
Copy link

Hi,

Any update on this, Can we expect something by this month end or early October?

@aahlenst
Copy link
Contributor

@madhu-broad Self-service instructions: #70 (comment)

@aahlenst
Copy link
Contributor

aahlenst commented Oct 3, 2020

I did some further research:

  • Genuine OpenJDK builds (jdk.java.net as well as the builds provided by Red Hat) don't come with Freetype on Linux.
  • https://docs.oracle.com/javase/9/intl/font-configuration-files.htm states that Windows is the last platform that OpenJDK provides font configuration for (macOS does not support font configuration anyway, support for Linux and Solaris was discontinued). The reason: "(...) Oracle JDK is moving away from providing custom font configuration files on Linux platforms, as they are difficult to keep up to date across distributions and versions."

Without Freetype, you get an error like:

Exception in thread "main" java.lang.UnsatisfiedLinkError: /root/jdk-11/lib/libfontmanager.so: libfreetype.so.6: cannot open shared object file: No such file or directory
        at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method)
        at java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2430)
        at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2487)
        at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2684)
        at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2638)
        at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:829)
        at java.base/java.lang.System.loadLibrary(System.java:1867)
        at java.desktop/sun.font.FontManagerNativeLibrary$1.run(FontManagerNativeLibrary.java:57)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.desktop/sun.font.FontManagerNativeLibrary.<clinit>(FontManagerNativeLibrary.java:32)
        at java.desktop/sun.font.SunFontManager$1.run(SunFontManager.java:270)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.desktop/sun.font.SunFontManager.<clinit>(SunFontManager.java:266)
        at java.base/java.lang.Class.forName0(Native Method)
        at java.base/java.lang.Class.forName(Class.java:398)
        at java.desktop/sun.font.FontManagerFactory$1.run(FontManagerFactory.java:82)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:74)
        at java.desktop/sun.java2d.SunGraphicsEnvironment.getFontManagerForSGE(SunGraphicsEnvironment.java:189)
        at java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:223)
        at java.desktop/sun.java2d.SunGraphicsEnvironment.getAvailableFontFamilyNames(SunGraphicsEnvironment.java:251)
        at java.desktop/sun.java2d.HeadlessGraphicsEnvironment.getAvailableFontFamilyNames(HeadlessGraphicsEnvironment.java:75)
        at FontTest.main(FontTest.java:7)

Install the packages as recommended in #70 (comment) and the problem is gone and you get proper integration with the operating system.

To sump up: I think we would get ourselves into trouble by providing font configuration or even fonts. Providing fonts and font configuration is not a problem to be tackeld on the level of the JDK but on the level of the operating system.

@aahlenst
Copy link
Contributor

aahlenst commented Oct 8, 2020

TSC decided not to bundle any fonts and to relegate the font handling to the operating system for the reasons documented in #70 (comment).

We're going to publish a blog post that explains how to install the fonts (AdoptOpenJDK/blog#498). We have instructions for Linux in #70 (comment). We need instructions for Solaris/AIX. We're also going to update the migration guide (AdoptOpenJDK/openjdk-website#799).

Later on, we can decide whether we remove Freetype from the binary builds (adoptium/temurin-build#2133). Probably best to do this together with the move to Eclipse.

@aahlenst aahlenst closed this as completed Oct 8, 2020
openjdk-support automation moved this from High priority to Closed Oct 8, 2020
Top Priorities automation moved this from In progress to Done Oct 8, 2020
@aahlenst aahlenst added wontfix This will not be worked on and removed TSC-Agenda labels Oct 8, 2020
jakaarl added a commit to Opetushallitus/baseimage that referenced this issue Nov 11, 2020
jakaarl added a commit to Opetushallitus/baseimage that referenced this issue Nov 11, 2020
jakaarl added a commit to Opetushallitus/baseimage that referenced this issue Nov 11, 2020
@gdams gdams removed this from Done in Top Priorities Mar 31, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working wontfix This will not be worked on
Projects
No open projects
openjdk-support
  
Closed
Development

No branches or pull requests