JavaFX 11 for JME


Np, all you need to do is this:

[code here]

I’ll try it out later today, I’m at least curious whether I’ll see similar issues.


Thanks a lot!:smiley:
Looking forward to your findings


I tried it on a 1280x720 video. The good news is, I didn’t notice any kind of lag or FPS choppiness issues. The bad news is I couldn’t reproduce the issue. lol

This was on Linux though, with a GTX 1070 and a pretty decent i7. So probably a pretty different setup. I was getting about 9000 FPS uncapped, consistent. When scaling to 1920x1080 from (approximately) the actual size, it dropped to about 5000 and stayed there.

Capped with:


JME FPS drops to a consistent 40. I guess that’s related to the the synchronization with JME’s thread.

With vsync you don’t need the setFrameRate(60), by the way. But also… if I ONLY do the setVSync - I get a solid 60 FPS.


Well that’s definitely good to here!!!
Yeah my PC isn’t equal to yours haha

Is there a way to private-message here? I don’t want to spam non-related things in here.
I am currently at refactoring, just to be sure would you help me test when I am finished with that?

JME FPS drops to a consistent 40. I guess that’s related to the synchronization with JME’s thread.

I noticed that too.

With vsync you don’t need the setFrameRate(60), by the way. But also… if I ONLY do the setVSync - I get a solid 60 FPS.

I know, I commented out “settings.setFrameRate(60)” and some other parts, but when pasting the code in here it complained I used too many links? e.g. //settings.setFrameRate60 :joy:


Click your avatar at the top right and click the envelope icon.

Don’t worry about spamming the thread, if it helps others then it’s not spam, it’s constructive :slight_smile:


Sure, if you think it’s helpful I can run some other tests later. If you use a code block like the example I put above, it won’t complain about “links”.


Convenient (Gradle) version of that media player test for anyone who wants to try it locally to see how it performs… Drop an mp4 into project root, update filename in code & as needed, run.

I tested in Linux, so of course it worked perfectly. :penguin: :laughing: Tests on inferior platforms advised.


I think I’ve fixed this. I’ll do a little more in-house testing but I’m pretty sure it’s solved.


This does work, but all it’s really doing is turning off the JVM’s “module aware mode” (at least that’s what the authors of the book on modularity I’m reading said to describe it).

run {
    doFirst {
        jvmArgs = [                

But yeah, I’ll help test whatever solution you’ve come up with.


I’ve pushed the changes to master. It appears to work fine for me. I’d be grateful if you wouldn’t mind seeing if it works.

This was the commit.


Oh that’s much better. Yeah that should work, I’ll give it a test run later.


Well, it did fix that problem. But it looks like it’s going to be a little harder for a working modular solution. And fixing the rest may not be so easy. Hopefully this isn’t too confusing:

Looking at the code, there’s quite a few more references to com.sun packages. All of those packages are off limits when the JVM is enforcing modular architecture rules (and they did it intentionally).	
import com.sun.javafx.embed.EmbeddedStageInterface;      [position 6:1]	
import;      [position 25:1]	
import com.sun.javafx.application.PlatformImpl;      [position 26:1]	
import com.sun.javafx.cursor.CursorFrame;      [position 27:1]	
import com.sun.javafx.embed.AbstractEvents;      [position 28:1]	
import com.sun.javafx.embed.EmbeddedSceneInterface;      [position 29:1]	
import com.sun.javafx.embed.EmbeddedStageInterface;      [position 30:1]	
import com.sun.javafx.embed.HostInterface;      [position 31:1]	
import com.sun.javafx.stage.EmbeddedWindow;      [position 32:1]	
import com.sun.javafx.cursor.CursorFrame;      [position 6:1]	
import com.sun.javafx.embed.EmbeddedSceneInterface;      [position 7:1]	
import com.sun.javafx.embed.EmbeddedStageInterface;      [position 8:1]	
import com.sun.javafx.stage.EmbeddedWindow;      [position 9:1]	
import com.sun.javafx.embed.EmbeddedSceneDSInterface;      [position 5:1]	
import com.sun.javafx.embed.EmbeddedSceneDTInterface;      [position 6:1]	
import com.sun.javafx.embed.EmbeddedSceneInterface;      [position 7:1]	
import com.sun.javafx.embed.HostDragStartListener;      [position 8:1]	
import com.sun.javafx.cursor.CursorFrame;      [position 8:1]	
import com.sun.javafx.embed.AbstractEvents;      [position 9:1]	
import com.sun.javafx.embed.EmbeddedSceneInterface;      [position 10:1]	
import com.sun.javafx.embed.EmbeddedStageInterface;      [position 11:1]	
import com.sun.javafx.embed.HostInterface;      [position 12:1]	
import com.sun.javafx.cursor.CursorFrame;      [position 3:1]	
import com.sun.javafx.cursor.CursorType;      [position 4:1]	
import com.sun.javafx.cursor.CursorFrame;      [position 10:1]	
import com.sun.javafx.cursor.CursorType;      [position 11:1]	
import com.sun.javafx.embed.AbstractEvents;      [position 16:1]	
import com.sun.javafx.embed.EmbeddedSceneInterface;      [position 17:1]	

So the new startup-time error that I get is this:

Uncaught exception thrown in Thread[main,5,main]
IllegalAccessError: superinterface check failed: class com.jayfella.jme.jfx.injme.JmeFxHostInterface (in unnamed module @0x77f9ed68) cannot access class com.sun.javafx.embed.HostInterface (in module because module does not export com.sun.javafx.embed to unnamed module @0x77f9ed68

Honestly though, I’m not sure this is really worth fixing at this time. Is anyone here using Java modules yet? I doubt it.

Even if we converted the project into a module and add the necessary requires commands, those sun packages aren’t being exported by They’d still be inaccessible.

It’s way easier to just remove the OpenJFX Gradle plugin’s runtime JVM parameters that’s causing the JVM to start in module-aware mode.

If there’s interest I can continue helping go further down this modular path, but I’m thinking nobody really needs this now? I expect removing all sun references to be a long term project.

Or I could donate a working demo which uses Java 11 + JME + OpenJFX-Gradle plugin. I’m only using it because they split JFX out of the base JDK after Java 10 and I don’t want the hassle of the extra setup. I think it needs an update to allow skipping the module parameters at runtime.

And now the “discourse” forum nanny is telling me to stop spamming the thread… :rofl:

Edit: Still researching the topic, there might be a way to get access to packages locked down by default… but a little distracted by other issues atm. :weary: