JMetro: NoSuchMethodError with no code written

[ghost]

JMetro v11.6.15 (using Maven) throws NoSuchMethodError with no JMetro imports or code written at all (i.e. mere dependency inclusion seems to be the cause). Shortened stack trace (if it's worth anything):

Exception in thread "JavaFX Application Thread" java.lang.NoSuchMethodError: 'void com.sun.javafx.scene.NodeHelper.recalculateRelativeSizeProperties(javafx.scene.Node, javafx.scene.text.Font)'
	at javafx.scene.control.Labeled$6.set(Labeled.java:375)
	at javafx.scene.control.Labeled$6.set(Labeled.java:347)
	at javafx.css.StyleableObjectProperty.applyStyle(StyleableObjectProperty.java:68)
	at javafx.scene.control.Labeled$6.applyStyle(Labeled.java:361)
	at javafx.scene.control.Labeled$6.applyStyle(Labeled.java:347)
	at javafx.scene.CssStyleHelper.transitionToState(CssStyleHelper.java:787)
	at javafx.scene.Node.doProcessCSS(Node.java:9647)
	at javafx.scene.Node.access$900(Node.java:398)
	at javafx.scene.Node$1.doProcessCSS(Node.java:471)
...
	at javafx.stage.Window$12.invalidated(Window.java:1086)
	at javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.stage.Window.setShowing(Window.java:1174)
	at javafx.stage.Window.show(Window.java:1189)
	at javafx.stage.Stage.show(Stage.java:273)
...

The stack trace suggests this happens when rendering the window, but a bit of debugging leads me to believe this happens at static initialization time. At first I thought it had something to do with my local configuration, but no resetting or clearing seems to solve the issue.

Java version: 17
JavaFX version: 17.0.2

[vkphd]

I can confirm that I am getting the same error and behavior trying to add JMetro to my simple project.

Java17, OpenJFX 18, JMetro 11.6.15 on Windows 10 using Maven.

[dylanvdbrink]

I am getting the same error, but I am only getting it when I initialize/setup JMetro in my scene with the following code:

...

JMetro jMetro = new JMetro(Style.LIGHT);
jMetro.setScene(scene); // <-- Removing/Commenting out this line fixes the error

For now I switched to the 8.6.14 version available on Maven Central, which does work. But you do need to set your Java version back to 8 which is not ideal for most (if not all) projects.

EDIT
Fixed it with the following version combination:
Java: 17
JavaFX: 16 (non-latest: everything above 16 seems to fail)
JavaFX Maven plugin version: 0.0.8
JMetro: 11.6.15 (latest)

[dukke]

Hi,

Sorry for the late reply but I've been very busy with my day to day work.

Is there any call to a Jmetro method or anything related to JMetro in the stacktrace of the exception? (I don't see any reference to JMetro in the stacktrace the reporter of this issue mentioned)

[vkphd]

I ran into this same error previously. My stack trace did not include any mention of Jmetro. In fact, I was able to trigger the same error even after removing all Jmetro usage from my project; however, because I still had the Jmetro dependency listed in my project, it triggered the same error ("Exception in thread "JavaFX Application Thread" java.lang.NoSuchMethodError: 'void com.sun.javafx.scene.NodeHelper.recalculateRelativeSizeProperties(javafx.scene.Node, javafx.scene.text.Font").

It seems there is some conflict between the jmetro and the javafx library that causes the javafx code to fail when the jmetro module is also loaded.

[dukke]

@vkphd Can you check if it also happens on different versions of Java and different versions of JavaFX?

[dukke]

BTW, this is a very strange bug. Unless I'm missing something I don't see how a dependency that's never used could trigger an exception..

Thanks

[dukke]

Anyways, please attach a small test app that illustrates the problem happening. This is the standard practice for any bug. Also, this is even more important given the small amount of resources and time available..

[bykka]

Here is my solution
Jmetro has in the dependencies a few outdated libraries:

   <dependency>
     <groupId>org.openjfx</groupId>
     <artifactId>javafx-graphics</artifactId>
     <version>11.0.2</version>
     <classifier>win</classifier>
     <scope>runtime</scope>
   </dependency>
   <dependency>
     <groupId>org.openjfx</groupId>
     <artifactId>javafx-controls</artifactId>
     <version>11.0.2</version>
     <classifier>win</classifier>
     <scope>runtime</scope>
   </dependency>

So, to make it work you need to explicitly include those libraries in your project with the proper versions. Otherwise javafx-controls of newer version tries to use javafx-graphics of older version

[dukke]

I'll need a small test app (as small as possible) so I can run and see the problem happening. Then I can also debug it.

[bykka]

https://github.com/bykka/JMetro_214
If to comment in the pom.xml lines 26-30 then it throws an exception

[dukke]

Thanks a lot for attaching a test app @bykka

[satsen]

@dukke I don't know if the issue I had a long time ago is related but this is what I did in my build.gradle. https://github.com/Satergo/Satergo/blob/52a3357ee7f25a332102a84cf65cbc523f956f6a/build.gradle#L56-L59. (Also, the exclusion of controlsfx is not needed anymore -- I wasn't using controlsfx so I didn't want it cluttering my final package -- because a new release with my PR that marks controlsfx as compileOnly was made) There is also a StackOverflow question about this, I think that's where I found the solution. It could be because JMetro is using the OpenJFX Gradle Plugin, which seems to be for applications more than libraries. Maybe you can compare with other JavaFX libraries.

Edit: The issue I was having is likely unrelated, but I do believe the one I had also still exists.

[dukke]

Thanks for your input guys!
At least we have the workaround that @bykka mentioned, so we already have a way to make this work. That is, explicitly import the javafx.graphics version that fits the javafx version you're using.

However it would be nice if we could prevent this exception from happening...

Ok, so after some investigation this seems a bit weird.

Both javafx.graphics version 11 and javafx.graphics version 18 have the method void com.sun.javafx.scene.NodeHelper.recalculateRelativeSizeProperties(javafx.scene.Node, javafx.scene.text.Font):

• javafx11 NodeHelper class - https://github.com/openjdk/jfx11u/blob/master/modules/javafx.graphics/src/main/java/com/sun/javafx/scene/NodeHelper.java

• javafx 18 NodeHelper class - https://github.com/openjdk/jfx/blob/28f8fa9c20363ced9a94787ecfd45735b3e6b82e/modules/javafx.graphics/src/main/java/com/sun/javafx/scene/NodeHelper.java#L287

Since we're using, for example, the Scene class there must be some javafx.graphics module being pulled in (Scene belongs to javafx.graphics) but even if the wrong version of javafx.graphics is pulled in (e.g. version 11 of javafx.graphics) it should still work or at least it shouldn't give the exception that it gives since the method in question exists in version 11.

[dukke]

...BTW, I'm trying to avoid changing the jmetro configuration and having it compile using javafx 17 for 2 reasons:

1. I could have a branch for javafx 11 and another branch for javafx 17 but that could be too much work for the amount of non payed hours I can spend on JMetro (since I would have to keep updating both branches, to keep them in sync).
2. I could simply change the master branch to compile using javafx 17 but that could bring up issues with developers that are on javafx 11 and using JMetro

[khaldi-yass]

Hello, after trying the workaround suggested by @bykka, a new issue appeared after initializing Jmeter class:

Error occurred during initialization of boot layer
java.lang.module.FindException: Module org.slf4j not found, required by com.jthemedetector

To reslove you need an additionnal dependency

      <dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-api</artifactId>
        <version>1.7.36</version>
    </dependency>

Environment:

• openjdk : 17.0.6
• open-javafx : 17.0.1
• sl4j : 2.7

[PolyRocketMatt]

This issue is still happening. Is there any fix for this being actively worked on?