JDK-8165342 : NPE when JavaFX loads default stylesheet or font families if CCL is null
  • Type: Bug
  • Component: javafx
  • Sub-Component: scenegraph
  • Affected Version: 8,9
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • Submitted: 2016-09-02
  • Updated: 2017-09-07
  • Resolved: 2017-03-23
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
8u131Fixed 9Fixed
Related Reports
Relates :  
JavaFX captures the Context Class Loader (CCL) of the calling thread at the time the JavaFX toolkit is initialized, and uses that as the CCL of the JavaFX Application Thread. We then use the CCL to locate user resources, and require it to be non-null in order for those resources to be located. Among these are CSS, FXML, Media, and Image if URIs without a protocol are used.

Starting in JDK 8, JavaFX also references the CCL when loading its own resources, such as loading the default style sheet and looking for embedded fonts, and does so in a way that causes those operations to abort with an NPE when the null CCL is referenced.

The two attached simple test programs illustrate this:

1. NullCCLControlTest -- constructs a Label (any UI control will fail similarly), which will load the default "modena.css" stylesheet

2. NullCCLHTMLEditorTest -- constructs and displays an HTMLEditor, which will load the default "modena.css" stylesheet, and then get a list of all font families.

In JDK 8, both test programs fail with an NPE and display nothing.

In JDK 9, the loading of the CSS resources has been fixed (as part of a larger bug fix for Jigsaw), so creating a Label or other UI control is able to load the stylesheet, but getting the list of font families still fails. So on JDK 9, test program #1 works, while test #2 fails with an NPE when the HTMLEditor tries to popuplate the list of fonts.

Original description is below

java.lang.ExceptionInInitializerError -
Caused by: java.lang.NullPointerException
 at com.sun.javafx.css.StyleManager.getURL(StyleManager.java:860)

The exception stack trace is same as in JDK-8093938

Changeset: 4e47c028792e Author: kcr Date: 2017-03-23 16:54 -0700 URL: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/4e47c028792e 8165342: NPE when JavaFX loads default stylesheet or font families if CCL is null Reviewed-by: jgiles, ckyang

Approved for inclusion into JDK 9.

Fix Request This is a behavioral regression with a simple, safe fix in JDK 9. Also, this fix (along with part of an earlier fix), needs to be backported to JDK 8u and needs to go into JDK 9 first.



WEBREV: FX 9: http://cr.openjdk.java.net/~kcr/8165342/9/webrev.00/ FX 8u: http://cr.openjdk.java.net/~kcr/8165342/8u/webrev.00/ EVALUATION: As indicated in the description, JavaFX should be able to load its own resources, such as the default stylesheet (modena.css) or the list of installed fonts, even if the CCL is null. There are two problems that need to be fixed: 1. Loading internal JavaFX stylesheets should be done without relying on the CCL. Starting with JDK 8, the loading of CSS stylesheets goes through common code regardless of whether it is an internal resource of JavaFX itself or an application resource. That common method needs to check for and load internal resources directly. We already made this change in JDK 9, so just need to backport that part of the fix to JDK 8u. 2. Enumerating the system fonts causes us to look for embedded fonts, which will fail if the CCL is null. A simple null check will solve this problem. We need to fix issue #1 in FX 8u and the issue #2 in both FX 9 and FX 8u.

Note that this is a regression from JDK 7 behavior.

There is one part of the more general issue that does affect JDK 9, so I am removing the "9-na" label and adding 9 in the affected version. Also, I'm setting the target to 9 and will create a JDK 8u backport.

Sustaining customer issue.

Please reopen with requested info (test case and check on 9)

Is there a test case? Note that JDK-8093938 was closed as "Cannot reproduce" because we didn't have a test case. Also, do we know whether this affects JDK 9?