Java 8 hang on "Choose installation directory"

[Cervator]

Reminding a fair bit of #239 - after resetting everything I could find to do final testing of #317 I started the launcher and it hung at the "Choose installation directory for the game..." step

I was running with Java 8 but compatibility at 7 still since I don't think we aim to be on 8 just yet (although we really should). Switching to Java 7 fixed it.

I can replicate it on Win7 here easily now on Java 8, and stepping through code it looks like javafx.concurrent.Task line 1437 is where you get dumped, and maybe the threading prevents a proper error from returning to the user.

There is Java 8 specific code in that JavaFX catch block (closure) which clearly wouldn't be the case in Java 7, but I don't know if that relates. Interestingly the process detaches from IntelliJ but the stalled window stays up, probably some thread is failing to exit.

Stopping in debug to where I can access the stuff in the Task class/thread I see:

java.lang.IllegalStateException: This operation is permitted on the event thread only; currentThread = Thread-4

[Cervator]

Huh, didn't mean to auto-close this, wonder how I triggered it. Open sesame!

Edit: We should fix this before officially requiring Java 8 for the launcher, so moved it back to an earlier milestone.

[Cervator]

After more testing I was able to provoke this on Java 7 as well :-(

I'm not convinced my results are dependable, however. Earlier testing was fine on Java 7 (and I believe with the new exes too)

[Cervator]

Did a fair bit more research on the topic.

So I get the point of JavaFX a bit more now, it gets bundled with Java 8, so you can distribute really light apps yet have access to nice UI classes. Cool.

You furthermore can bundle a JRE with JavaFX in it so sure, your app gets a little bigger again, but now it doesn't require Java installed at all. Also cool.

@shartte - is the JRE bundling we've tested including the JavaFX bundle? It would probably have to be for the launcher.

On testing locally what works is running Java 7 from source in IntelliJ, which puts the JavaFX jar from the JRE's lib/ext dir on the classpath automatically. Even reverting to Java 7 in build.gradle, however, doesn't let a Java 7 compiled launcher work. It fails to find the FX jar if you launch with java -jar lib/TerasologyLauncher.jar. At least for me.

I could make it work by embedding the Java 7 FX jar as a lib in Gradle, making it come along with the compiled launcher. In that case running with Java 7 from binary worked! But then promptly failed with Java 8 as its FX jar gets favored and then stalls the game on the file chooser dialog as usual.

As an added aside I ran across https://www.raspberrypi.org/forums/viewtopic.php?t=97367 during my journey, apparently FX got dropped from the ARM version of the JRE. It also made me concerned about OpenJDK/OpenFX, but there again what needs to save us is JRE 8 bundling with FX (and this bug fixed).

Not that I'm particularly worried about lacking FX in an ARM setting (think Raspberry Pi) since I don't imagine we have a lot of likely use there, but it reveals some portability questions.

Anyway - head hurty. @skaldarnar save me! You're the only hope for the rebel alliance and the people of Alderaan.

[skaldarnar]

I was researching this issue as well, but did not manage to narrow it further down. I recall that FX should be included in the bundled JRE (had some discussions with @shartte some time ago). I'm not sure whether this issue is really related to the FX jar (or rather, how exactly it is related) - the other UI features work as expected once the directory is set.
I try to test it again tonight, hopefully with better results.

[skaldarnar]

Got it! The init-thread is just started off the main thread instead of using Platform.runLater().

[Cervator]

Woohoo! Thank you so much! :-)

Will see about merging and releasing a 2.0.1 later then, with Java 8 required.