comment #0 suggests this is F29. Adjusting version. FWIW, it can't be rawhide as it's been fixed there already with https://koji.fedoraproject.org/koji/buildinfo?buildID=1171787

This link is missing:
ln -s /usr/lib/jvm/openjfx/rt/lib/amd64/libglassgtk2.so /usr/lib/jvm/java-1.8.0-openjdk/jre/lib/amd64/

I think the bug 1657485 will be closed when openjdk8 u202 will be released this month

(In reply to Nicolas De Amicis from comment #2)
> I think the bug 1657485 will be closed when openjdk8 u202 will be released
> this month

No it's unrelated to a potential u202 update. I'll backport symlink fixes into stable Fedora releases and will file an update when that's done. Feel free to close this bug as a duplicate of 1657485.

*** This bug has been marked as a duplicate of bug 1657485 ***

yep, F29, I have to pay better attention to bugzilla's default field values ...

however, I have to reopen; bug #1657485 deals with the second part but not with my initial problem

after cleaning up and reinstalling, openjfx still doesn't pull in java-1.8.0-openjdk-openjfx so trying to run the app ends in error:

$ java -Dprism.verbose=true -jar MiUnlockTool.jar
Exception in thread "main" java.lang.NoClassDefFoundError: javafx/application/Application
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        at com.xiaomitool.miunlock.Main.main(SourceFile:46)
Caused by: java.lang.ClassNotFoundException: javafx.application.Application
        at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        ... 13 more


while after installing java-1.8.0-openjdk-openjfx it looks much better:

$ java -Dprism.verbose=true -jar MiUnlockTool.jar
Prism pipeline init order: es2 sw 
Using java-based Pisces rasterizer
Using dirty region optimizations
Not using texture mask for primitives
Not forcing power of 2 sizes for textures
Using hardware CLAMP_TO_ZERO mode
Opting in for HiDPI pixel scaling
Prism pipeline name = com.sun.prism.es2.ES2Pipeline
Loading ES2 native library ... prism_es2
        succeeded.
...

Do you have installed openjfx symlinks package like : dnf install java-1.8.0-openjdk-openjfx ?

Which versions of packages have you installed?

I have tested MiUnlockTool.jar and it seems that libjfxwebkit.so is needed, but it's not provided by Fedora openjfx package (see bug https://bugzilla.redhat.com/show_bug.cgi?id=1547378, I have not yet work on this subject):
java.lang.UnsatisfiedLinkError: Can't load library: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.191.b13-0.fc29.x86_64/jre/lib/amd64/libjfxwebkit.so

(In reply to Karel Volný from comment #5)
> however, I have to reopen; bug #1657485 deals with the second part but not
> with my initial problem

Hmm, your original problem was:
"Caused by: java.lang.UnsatisfiedLinkError: Can't load library: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.191.b12-11.fc29.x86_64/jre/lib/amd64/libglassgtk2.so"

The other problem you are describing is related to the symlinks from java-1.8.0-openjdk missing to openjfx. That's a different problem and cannot be fixed without introducing a circular dependency. See below.

> java-1.8.0-openjdk-openjfx so trying to run the app ends in error:

If it was, we'd have circular dependencies: java-1.8.0-openjdk-openjfx => openjfx => java-1.8.0-openjdk-openjfx

> while after installing java-1.8.0-openjdk-openjfx it looks much better:

Yes, that's the way to go.

Aside: We should recommend people installing java-1.8.0-openjdk-openjfx rather than just openjfx.

(In reply to Nicolas De Amicis from comment #6)
> Do you have installed openjfx symlinks package like : dnf install
> java-1.8.0-openjdk-openjfx ?

at first, no

> I have tested MiUnlockTool.jar and it seems that libjfxwebkit.so is needed,
...

to be honest, as for the log in #c5, I just stopped it after seeing it's loading, and didn't wait for the app startup, so I don't know whether there is something else - I didn't have the machine at hand, I tested remotely without X, so there was no point trying further ... I'll get to it over the weekend, hopefully

(In reply to Severin Gehwolf from comment #7)
> (In reply to Karel Volný from comment #5)
> > however, I have to reopen; bug #1657485 deals with the second part but not
> > with my initial problem
> 
> Hmm, your original problem was:
> "Caused by: java.lang.UnsatisfiedLinkError: Can't load library:
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.191.b12-11.fc29.x86_64/jre/lib/amd64/
> libglassgtk2.so"

nope, when reading from top of the description, there is

java.lang.UnsatisfiedLinkError: Can't load library: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.191.b12-11.fc29.x86_64/jre/lib/amd64/libprism_es2.so

that has gone away after installing java-1.8.0-openjdk-openjfx

...
> If it was, we'd have circular dependencies: java-1.8.0-openjdk-openjfx =>
> openjfx => java-1.8.0-openjdk-openjfx

er, a stupid question ... is that a bad thing?

one package would pull the other, both would be installed in one transaction, with both dependecies satisfied, is there any problem with that?

> Aside: We should recommend people installing java-1.8.0-openjdk-openjfx
> rather than just openjfx.

I don't know which random Googled howto I had followed, I guess this is completely out of your control :-(

(In reply to Karel Volný from comment #8)
> > If it was, we'd have circular dependencies: java-1.8.0-openjdk-openjfx =>
> > openjfx => java-1.8.0-openjdk-openjfx
> 
> er, a stupid question ... is that a bad thing?
> 

It can be. For example, it creates a problem of bootstrapping new architectures and distros (where neither package can be built because the other is not built.) There are ways around this, but not without increasing maintenance burden.

(In reply to Karel Volný from comment #8)
> er, a stupid question ... is that a bad thing?

openjfx only works on a few architectures, so then openjdk would break on many installations.

We could have some kind of meta-package or include some user friendly provides in the java-1.8.0-openjdk-openjfx package. Then we could tell users to just run 'dnf install javafx' for instance.

(In reply to Mat Booth from comment #9)
> (In reply to Karel Volný from comment #8)
> > > If it was, we'd have circular dependencies: java-1.8.0-openjdk-openjfx =>
> > > openjfx => java-1.8.0-openjdk-openjfx
> > 
> > er, a stupid question ... is that a bad thing?
> > 
> 
> It can be. For example, it creates a problem of bootstrapping new
> architectures and distros (where neither package can be built because the
> other is not built.) There are ways around this, but not without increasing
> maintenance burden.

I don't know how that works for java, but I'd think that the build shouldn't be a problem as long as *BuildRequires* don't depend on each other ...?

(In reply to Jonny Heggheim from comment #10)
> openjfx only works on a few architectures, so then openjdk would break on
> many installations.

well, if there is new Requires: java-1.8.0-openjdk-openjfx in *openjfx*, how could that influence architectures where there is no openjfx?

> We could have some kind of meta-package or include some user friendly
> provides in the java-1.8.0-openjdk-openjfx package. Then we could tell users
> to just run 'dnf install javafx' for instance.

not sure how a meta-package would solve the situation when 'dnf install some_random_package' doesn't pull the libraries needed to use it

having to know that instead of some_random_package I need to install some_meta-package which pulls in both some_random_package and some_random_package's_dependency resembles 1990's rpm dependency hell, not almost 2020's nifty dnf

...

guys, I don't know what's doable in case of java packages, so please take the above easily

I'm just presenting the user point of view:

- I need to run this tool
- the author says[*] it needs javafx and that it might be provided by openjfx: "If you get some errors with javafx class not found stuff when you try to launch the gui, then you are missing javafx library. See openjfx package on linux."
- dnf install openjfx
- kaboom, the tool doesn't run

that's not how'd I expect it to work; and unfortunately, changing every googleable resource to say that in Fedora it is not 'openjfx' but 'java-1.8.0-openjdk-openjfx' is impossible

(yes, in this particular case you can ask the author to update the instructions, but how many other packages and instructions are out there?)

[*] https://forum.xda-developers.com/android/software-hacking/tool-miunlocktool-unlock-bootloader-t3782444

I think the history of JavaFX explains the problem:
- Before Java 7, JavaFX was separate
- With Java 7, JavaFX was included but not loaded in classpath by default
- With Java 8, JavaFX was included and loaded by default
- After Java 8, JavaFX was separate from Java

The symlink is an elegant way to manage openjdk and openjfx separately and then link them. It is true that this can be confusing for the end user. I do not see how to manage differently.
For the problem of libjfxwebkit.so please refer to https://bugzilla.redhat.com/show_bug.cgi?id=1547378