Broken dependencies

[G4Zz0L1]

The newest addition liberica-jre-11-full is missing on AUR. We either have liberica-jre-11-bin or liberica-jre-11-full-bin. I think the PKGBUILD should include the second.

[rednoah]

Either one will probably work fine. liberica-jre-11-full-bin. should work. We need the -full edition because that one includes the OpenJFX modules that we need for the GUI.

On a related note. Should we use the absolute path to the java executable in liberica-jre-11-bin instead of just using java and relying on the $PATH?

[G4Zz0L1]

I honestly don't know, java is way beyond my scope. Why don't we use the official repo packages for java11 (like jre11-openjdk and java11-openjfx) instead of relying on some package from AUR?

[rvasilev]

@rednoah Filebot.sh could be tuned for this so user will not be forced to use liberica as system java runtime.

[rvasilev]

@G4Zz0L1 Good point, but explanation is https://github.com/arch-noob/filebot/issues/12#issuecomment-704651028

[rednoah]

Using jre11-openjdk and java11-openjfx should be possible, but will require additional configuration via filebot.sh to add the JavaFX modules to the module search path.

e.g. here's what filebot.sh does on Debian Linux when installed via apt relying on OpenJFX from the repository:

...
MODULE_PATH=/usr/share/openjfx/lib
...
java ... --module-path "$MODULE_PATH" --add-modules ALL-MODULE-PATH
...

[G4Zz0L1]

@rvasilev Oh, ok. My fault, I could RTFM xD

@rednoah If it's too much of a hassle, we can drop it and just change the PKGBUILD with the correct build of liberica (which is liberica-jre-11-full-bin)

[rednoah]

I think lock-in on jre11-openjdk and java11-openjfx might be preferable to the majority of users, if it works out-of-the-box.

(just recommended liberica-jre-11-full-bin in recent support requests because some users found it difficult to patch up filebot.sh manually; which may have been a PEBKAC kinda problem rather than a technical limitation)

[rvasilev]

@rednoah

Using jre11-openjdk and java11-openjfx should be possible, but will require additional configuration via filebot.sh to add the JavaFX modules to the module search path.

e.g. here's what filebot.sh does on Debian Linux when installed via apt relying on OpenJFX from the repository:

...
MODULE_PATH=/usr/share/openjfx/lib
...
java ... --module-path "$MODULE_PATH" --add-modules ALL-MODULE-PATH
...

even without defining MODULE_PATH looks like it is working (starting with no errors) with original filebot.sh and jre11-openjdk + java11-openjfx.

and absolute path should be used to rely on jre11 /usr/lib/jvm/java-11-openjdk/bin/java.

I'll update the package and filebot.sh to get more feedback.

[rvasilev]

@rednoah @G4Zz0L1 https://github.com/arch-noob/filebot/commit/d026ab0a1abf536d8ec73366e5cfbb133da5f875 is online

[rednoah]

If you run filebot to open the GUI and then click on the Load button, then that should allow you to test if OpenJFX is working or not. If OpenJFX is working, then a nice Gnome File Dialog will open up. If not, then there will be errors in the console, and a very basic old-school Java Swing File Dialog will open up.

[G4Zz0L1]

Thanks, it works. So I think we can close it now.

[rvasilev]

Failed to initialize JavaFX: javafx/embed/swing/JFXPanel
java.lang.NoClassDefFoundError: javafx/embed/swing/JFXPanel
    at net.filebot.util.ui.SwingUI.useJavaFX(Unknown Source)
    at net.filebot.UserFiles$FileChooser$5.showLoadDialogSelectFiles(Unknown Source)
    at net.filebot.UserFiles.selectSelectFiles(Unknown Source)
    at net.filebot.UserFiles.lambda$showLoadDialogSelectFiles$0(Unknown Source)
    at net.filebot.UserFiles.lambda$withModeSelect$1(Unknown Source)
    at net.filebot.util.ui.SwingUI.withWaitCursor(Unknown Source)
    at net.filebot.UserFiles.lambda$withModeSelect$2(Unknown Source)
    at net.filebot.util.ui.SwingUI.lambda$invokeLater$9(Unknown Source)
    at net.filebot.UserFiles.withModeSelect(Unknown Source)
    at net.filebot.UserFiles.showLoadDialogSelectFiles(Unknown Source)
    at net.filebot.ui.transfer.LoadAction.actionPerformed(Unknown Source)
Caused by: java.lang.ClassNotFoundException: javafx.embed.swing.JFXPanel
    at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
    at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
    ... 11 more

Kind of works

[rvasilev]

@G4Zz0L1 kinda fixed, please confirm. No errors dropped to console and nice dialog pops up.

[rvasilev]

@rednoah is there any way to provide openjfx modules to java runtime without messing with copying/symlinking files?

e.g.

do not this

java ... --module-path "$MODULE_PATH" --add-modules ALL-MODULE-PATH

but do that

java ... --modules "javafx.*"

?

[G4Zz0L1]

It works fine here, even the load button window.

[rednoah]

Well, we could specify specific modules via --add-modules but the JDK that doesn't help with finding them in the first place. --module-path is always going to be required if they're not built-in, but somewhere in the file system instead.

Note that there's no copying or symlinking involved. We just need to specify the path where the OpenJFX package puts the module files:

--module-path /path/to/modules

[rednoah]

* I see that the AUR OpenJFX package just copies the files into the `java-11-openjdk/lib/javafx.` folder. Merging modules into the JDK folder does nothing. The files could be anywhere, and putting them in the JDK folder doesn't automatically add them to the module path.

[rednoah]

Perhaps something like this will do:

MODULE_PATH=$(echo /usr/lib/jvm/java-*-openjdk/jmods | tr ' ' ':')
...
java ... --module-path "$MODULE_PATH" ...

[rvasilev]

@rednoah This way vs copying javafx to the workdir like debian package does vs symlinking like in the last aur package.

The way without polluting filesystem looks more logic and consistent. Or I'm missing something?

[rednoah]

The platform-independent Debian package does this as well:

# select libjnidispatch.system.so from $(uname -m)-linux-gnu folder
LIBRARY_PATH=$(echo /usr/lib/*-linux-gnu*/jni | tr ' ' ':')
MODULE_PATH=/usr/share/openjfx/lib

We do have a amd64-only package for Debian package as well, but that's different in that it includes JRE/JFX as part of the application bundle and thus doesn't have any external dependencies. I could do that for the aur package as well, but that means amd64 only, which may or may not be a problem for the aur community.

[evilsh3ll]

I still have this problem in 5.0.3 version, how can I fix?