Symptom
Repeated WARN-level CSS failures on JavaFX 27-ea:
j.css - Caught java.lang.ClassCastException: class java.lang.String cannot be cast to class javafx.scene.paint.Paint
while converting value for -fx-background-color from rule *.reasoner-result-header *.label in stylesheet .../kview.css
j.css - ... from rule *.search-sort-button in stylesheet .../kview.css
Analysis
Both rules use looked-up colours defined only in kview.css's .root block:
.search-sort-button { -fx-background-color: -Secondary-05; ... }
.reasoner-result-header .label { -fx-background-color: -Grey-9; ... }
.root { -Grey-1: #FBFBFC; ... } /* all palette variables */
kview.css is frequently attached to FXML fragments (stylesheets="@../kview.css" on a sub-pane). A stylesheet attached at a sub-pane applies only to that pane and below, so its .root rule never matches the scene root there. In any scene where kview.css arrives only via a fragment — the reasoner result surface, the navigator search area — the palette variables are undefined at the point of use. JavaFX 27-ea's converter reports the unresolved lookup as the String→Paint ClassCastException above (earlier releases logged a quieter could-not-resolve warning).
This is not only log noise: the affected -fx-background-color (and any other looked-up value in that scene) silently fails to apply, so those controls render unstyled in exactly the fragment-attached contexts.
Not introduced by current branch work — kview.css has no changes against main; the trigger is the 27-ea pin (see the JavaFX 27-ea+24 pin rationale in komet-bom) making a long-standing scoping gap loud.
Fix directions
- Ensure the palette variables reach every scene that uses kview.css fragments: either attach kview.css (or a dedicated palette stylesheet containing only the variable block) at the scene/application level for every window and popup, or
- move the variable block from
.root to * scope in kview.css (broader matching, with the usual specificity cautions), or
- stop attaching kview.css per-fragment and rely on application-level attachment alone.
Acceptance
- No
String cannot be cast to ... Paint warnings from kview.css rules at startup or when opening the reasoner results and navigator search surfaces.
.search-sort-button and .reasoner-result-header .label render their palette backgrounds in every window they appear in.
Symptom
Repeated WARN-level CSS failures on JavaFX 27-ea:
Analysis
Both rules use looked-up colours defined only in kview.css's
.rootblock:kview.css is frequently attached to FXML fragments (
stylesheets="@../kview.css"on a sub-pane). A stylesheet attached at a sub-pane applies only to that pane and below, so its.rootrule never matches the scene root there. In any scene where kview.css arrives only via a fragment — the reasoner result surface, the navigator search area — the palette variables are undefined at the point of use. JavaFX 27-ea's converter reports the unresolved lookup as the String→Paint ClassCastException above (earlier releases logged a quieter could-not-resolve warning).This is not only log noise: the affected
-fx-background-color(and any other looked-up value in that scene) silently fails to apply, so those controls render unstyled in exactly the fragment-attached contexts.Not introduced by current branch work —
kview.csshas no changes against main; the trigger is the 27-ea pin (see the JavaFX 27-ea+24 pin rationale in komet-bom) making a long-standing scoping gap loud.Fix directions
.rootto*scope in kview.css (broader matching, with the usual specificity cautions), orAcceptance
String cannot be cast to ... Paintwarnings from kview.css rules at startup or when opening the reasoner results and navigator search surfaces..search-sort-buttonand.reasoner-result-header .labelrender their palette backgrounds in every window they appear in.