JabRef not working on Arch Linux

[aytekinar]

• I have tested the latest development version from http://builds.jabref.org/master/ and the problem persists

I am on an Arch Linux machine with the following:

~/JabRef> git branch -vv
* master 4add3167c [origin/master] Bump jaxb-xjc from 2.2.4-1 to 2.3.2 (#4956)
~/JabRef> pacman -Q | grep -i java
java-environment-common 3-1
java-runtime-common 3-1
~/JabRef> archlinux-java status
Available Java environments:
  java-11-openjdk (default)
~/JabRef> java --version
openjdk 11.0.4 2019-07-16
OpenJDK Runtime Environment (build 11.0.4+11)
OpenJDK 64-Bit Server VM (build 11.0.4+11, mixed mode)
~/JabRef> git submodule status 
 e89e6b08b5c621a414fc7114f2129efac5f8c7d5 src/main/resources/csl-locales (heads/master)
 83603de7a7f4652f8d1733f18f0c00be8974948e src/main/resources/csl-styles (heads/master)

Steps to reproduce the behavior:

1. gradle releaseJar or gradle shadowJar (see log)
2. java -jar build/releases/JabRef-5.0-dev.jar

I have a failure with the following error:

Error: Could not find or load main class org.jabref.org.jabref.JabRefLauncher
Caused by: java.lang.ClassNotFoundException: org.jabref.org.jabref.JabRefLauncher

Log File

> Task :buildSrc:compileJava NO-SOURCE
> Task :buildSrc:compileGroovy
> Task :buildSrc:processResources NO-SOURCE
> Task :buildSrc:classes
> Task :buildSrc:jar
> Task :buildSrc:assemble
> Task :buildSrc:compileTestJava NO-SOURCE
> Task :buildSrc:compileTestGroovy NO-SOURCE
> Task :buildSrc:processTestResources NO-SOURCE
> Task :buildSrc:testClasses UP-TO-DATE
> Task :buildSrc:test NO-SOURCE
> Task :buildSrc:check UP-TO-DATE
> Task :buildSrc:build

> Configure project :
Found module name 'org.jabref'

> Task :generateBibtexmlSource
> Task :generateBstGrammarSource
> Task :generateEndnoteSource
> Task :generateMedlineSource
> Task :generateModsSource
> Task :generateSearchGrammarSource
> Task :generateSource

> Task :compileJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :processResources
> Task :classes
> Task :shadowJar
> Task :releaseJar

Deprecated Gradle features were used in this build, making it incompatible with Gradle 6.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/5.6.1/userguide/command_line_interface.html#sec:command_line_warnings

BUILD SUCCESSFUL in 37s
10 actionable tasks: 10 executed

[Siedlerchr]

I also experience this under windows when I use the jar. @tobiasdiez any idea?

[tobiasdiez]

With modularized Java 11 applications, the jar file does no longer work / is no longer the supported distribution mechanism. Instead, you should create a runtime image using gradle jlink and then run it via java -m org.jabref/org.jabref.JabRefLauncher.

[aytekinar]

Thanks to both of you for your fast responses.

@tobiasdiez, I can confirm that running

gradle jlink
gradle run

compiles and runs JabRef without any problems. However, I cannot make it work with

gradle jlink
java -m org.jabref/org.jabref.JabRefLauncher

when working under the source tree. The command gives the following error this time:

Error occurred during initialization of boot layer
java.lang.module.FindException: Module org.jabref not found

When I run tree -L 2 build, I get the following:

build
├── classes
│   └── java
├── generated
│   └── sources
├── image
│   ├── bin
│   ├── conf
│   ├── legal
│   ├── lib
│   └── release
├── jlinkbase
│   ├── delegating
│   ├── jlinkjars
│   ├── mergedjars
│   ├── nonmodjars
│   ├── tmpjars
│   ├── tmpmerged
│   └── tmpmodinfo
├── libs
│   └── JabRef-5.0-dev.jar
├── resources
│   └── main
└── tmp
    ├── compileJava
    └── jar

I am assuming that

• either I need to move some parts of build to a specific path under my user space, or
• I need to use the --module-path switch to java when running the module.

I would appreciate if you provided a minimal working example. Then, I can write a PKGBUILD file for my system or update the paths under my user space accordingly.

[aytekinar]

Final comment...

As of 18cf80f, the following PKGBUILD file works for Arch Linux:

pkgname=jabref
pkgver=r13251.18cf80f95d
pkgrel=1
pkgdesc='Graphical Java application for managing BibTeX and biblatex (.bib) databases.'
arch=('x86_64')
url='https://www.jabref.org'
license=('MIT')

source=("git+https://github.com/JabRef/jabref")
sha256sums=('SKIP')

makedepends=('gendesk' 'gradle' 'jdk-openjdk')

provides=('jabref')
conflicts=('jabref')

prepare() {
  gendesk ../PKGBUILD
  sed 's|Exec=jabref|Exec=/opt/jabref/image/bin/JabRefMain|g' --in-place jabref.desktop
}

pkgver() {
  cd "${pkgname}"
  printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
}

build() {
  cd "${srcdir}/${pkgname}"
  git submodule update --init
  gradle jlink
}

package() {
  cd "${srcdir}"
  install -d "${pkgdir}/opt"
  cp -R "${pkgname}/build" "${pkgdir}/opt/jabref"
  install -D jabref.desktop "${pkgdir}/usr/share/applications/jabref.desktop"
  install -D jabref.png "${pkgdir}/usr/share/pixmaps/jabref.desktop"
}

Basically, after gradle jlinking, moving everything under build to /opt/jabref and running /opt/jabref/image/bin/JabRefMain from a desktop file works. The only problem, though, is the installed package size: 705.38 MiB. I would appreciate if there were a way to make the package smaller (i.e., perhaps installing things the "jar" way).

[Siedlerchr]

Thanks for the update. That size is indeed huge, I found out that this is somehow a linux issue with jlink and that there is a workaround for reducing the size:
$ strip -p --strip-unneeded lib/server/libjvm.so
docker-library/openjdk#217 (comment)

[tobiasdiez]

@aytekinar It should suffice to use what is inside of build/image after gradle jlink. The bin folder should contain a luncher script (JabRefMain.bat on Windows).

[aytekinar]

@Siedlerchr I will try to do the manual stripping. However, Arch Linux also does stripping when packaging binaries.

@tobiasdiez I would appreciate if you could write an MWE for that. I can get rid of the bin directory, but I do not know how to launch JabRef in this new way. See my comment above.

[tobiasdiez]

I have no linux at hand, so I cannot give more details sorry. On Windows, the build/image/bin folder contains JabRefMain.bat and if I click on this file JabRef starts successfully. I would guess that the same folder contains a luncher (JabRefMain.sh?) also on linux. If not can you please paste the content of that folder here. Thanks

[aytekinar]

Update 1. Stripping the image manually as suggested by @Siedlerchr, as of a357bbd, still results in 705.38 MiB.

Update 2. image/bin contains the following:

~> tree /opt/jabref/image/bin/
/opt/jabref/image/bin/
├── JabRefMain
├── JabRefMain.bat
├── jar
├── jarsigner
├── java
├── javac
├── javadoc
├── javap
├── jdeprscan
├── jdeps
├── jfr
├── jimage
├── jlink
├── jmod
├── jrunscript
├── keytool
├── rmid
├── rmiregistry
└── serialver

and its size is

~> du --summarize --human-readable /opt/jabref/image/bin/
284K	/opt/jabref/image/bin/

In fact, JabRefMain is a shell script, as you have guessed @tobiasdiez, with the following content:

#!/bin/sh
DIR="${0%/*}"
"$DIR/java"  -p "$DIR/../app" -m org.jabref/org.jabref.JabRefLauncher  "$@"

which uses the java binary under the same directory to point to the app path in the directory above. Weird enough, find /opt/jabref/ -name app gives nothing (i.e., there is no such directory or file inside the package).

In short,

1. stripping the libraries manually did not help because I assume that Arch Linux's package manager (pacman) strips the binaries by default if not instructed otherwise,
2. image/bin directory is not the bottleneck (i.e., it has 284K size).

That said, I think this issue is not open anymore. Anybody with a problem on Arch Linux can see the solution you have suggested and either use my PKGBUILD suggestion above or find their way accordingly.

Edit. For your reference, the package size has the following distribution among the package's modules/directories:

~> du --summarize --human-readable /opt/jabref/*
11M	/opt/jabref/classes
20K	/opt/jabref/generated
161M	/opt/jabref/image
581M	/opt/jabref/jlinkbase
14M	/opt/jabref/libs
60M	/opt/jabref/resources
16K	/opt/jabref/tmp
~> du --summarize --human-readable /opt/jabref/image/*
284K	/opt/jabref/image/bin
120K	/opt/jabref/image/conf
404K	/opt/jabref/image/legal
160M	/opt/jabref/image/lib
4,0K	/opt/jabref/image/release
~> du --summarize --human-readable /opt/jabref/jlinkbase/*
292K	/opt/jabref/jlinkbase/delegating
104M	/opt/jabref/jlinkbase/jlinkjars
296M	/opt/jabref/jlinkbase/mergedjars
96M	/opt/jabref/jlinkbase/nonmodjars
580K	/opt/jabref/jlinkbase/tmpjars
87M	/opt/jabref/jlinkbase/tmpmerged
16K	/opt/jabref/jlinkbase/tmpmodinfo