JabRef ignores Djava.util.prefs.userRoot

[rolandog]

JabRef version

5.5 (latest release)

Operating system

GNU / Linux

Details on version and operating system

Ubuntu 21.10 x86_64 with GNOME 40.5

Checked with the latest development build

• I made a backup of my libraries before testing the latest development version.
• I have tested the latest development version and the problem persists

Steps to reproduce the behaviour

1. Use previous versions of JabRef, and decide to implement XDG Base Directory standard specs
2. Having set export_JAVA_OPTIONS variable to use XDG Base Directory specification:
   • export _JAVA_OPTIONS=-Djava.util.prefs.userRoot="$XDG_CONFIG_HOME"/java
   • (probably restart your session, or reboot)
3. Move ~/.java to $XDG_CONFIG_HOME/java
4. Install JabRef
5. Launch JabRef (this is where ~/.java gets created again)

Appendix

On a positive note

$XDG_DATA_HOME is properly followed, as can be seen from the logs when creating the index.

Fix SSL exceptions by accepting ALL certificates
Could not access app-directory at /home/rolandog/.local/share/JabRef
java.nio.file.NoSuchFileException: /home/rolandog/.local/share/JabRef
	at java.base/sun.nio.fs.UnixException.translateToIOException(Unknown Source)
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(Unknown Source)
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(Unknown Source)
	at java.base/sun.nio.fs.UnixFileSystemProvider.newDirectoryStream(Unknown Source)
	at java.base/java.nio.file.Files.newDirectoryStream(Unknown Source)
	at org.jabref@5.6.47/org.jabref.gui.JabRefMain.clearOldSearchIndices(Unknown Source)
	at org.jabref@5.6.47/org.jabref.gui.JabRefMain.start(Unknown Source)
	at org.jabref.merged.module@5.6.47/com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(Unknown Source)
	at org.jabref.merged.module@5.6.47/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(Unknown Source)
	at org.jabref.merged.module@5.6.47/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(Unknown Source)
	at java.base/java.security.AccessController.doPrivileged(Unknown Source)
	at org.jabref.merged.module@5.6.47/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(Unknown Source)
	at org.jabref.merged.module@5.6.47/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(Unknown Source)
	at org.jabref.merged.module@5.6.47/com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method)
	at org.jabref.merged.module@5.6.47/com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$11(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)

...

Index path for /home/rolandog/Documents/references/rg-references.bib is /home/rolandog/.local/share/JabRef/0.5a
Index path for /home/rolandog/Documents/references/rg-references.bib is /home/rolandog/.local/share/JabRef/0.5a

[rolandog]

I was trying to verify if this may be an upstream bug, but it seems that users may be able to partially override the configuration location, so it's possible that this is an actual bug.

[Siedlerchr]

I am having no LInux here atm and first time I hear about this.
JabRef ships with it's own jdk version, can you try to modify the launch script under jabref/lib/runtime
See here for to adjust the launcher: https://discourse.jabref.org/t/hidpi-scaling-ignored-in-jabref-5-2/2512/3?u=siedlerchr

[rolandog]

Hi @Siedlerchr , thanks again for your response!

I tried the following options:

• Setting [JavaOption]'s value in /opt/jabref/lib/app/ to java-options=-Djpackage.app-version=5.6.47 -Djava.util.prefs.userRoot="$XDG_CONFIG_HOME"/java
• Inserting the previous option right after "$DIR/java" in /opt/jabref/lib/runtime/bin/JabRef
• Testing and adding the options to the $CDS_JVM_OPTS variable.

In all cases a new .java/.userPrefs/org/jabref/ folder was created in the home directory (and $XDG_CONFIG_HOME/java/.userPrefs/org/jabref/ was ignored).

However, I'm not sure if there are other tests going on that may nudge JabRef (or Java) to create the file in $HOME:

I was progressing alphabetically in moving or categorizing some folders to their respective $XDG_CONFIG_HOME, $XDG_DATA_HOME, or $XDG_STATE_HOME ... and I still hadn't reached the letter 'o', so I hadn't noticed that I still needed to move ~/.org.jabref.gui.JabRefMain/ and ~/.org.jabref.JabRefMain/.

Could these directories be nudging JabRef to think that it must write in $HOME? If so, where should I place them?

[Siedlerchr]

NO idea, though, JabRef does use the normal Java preferences mechanism, so the thing should work. Have you tried with the absolute path in the switch and starting from terminal ./jabref afterwards?

I only found this guide which mentions this in the last section as well
https://docs.oracle.com/en/java/javase/17/core/preferences-api1.html#GUID-2DAC3DD0-993A-41A8-8CDC-F8E3A72E1AE3

[rolandog]

Interesting... I went ahead and did some poking around, and I had many things to report back, so... sorry for a huge write-up.

Java options

So, I wanted to learn a bit more about the options passed on to java, and---to my surprise---the first line was confirming that it had properly detected the _JAVA_OPTIONS environment variable:

user@computer:~$ java --help
Picked up _JAVA_OPTIONS: -Djava.util.prefs.userRoot=/home/rolandog/.config/java
...

And this was also the case for the bundled java program:

user@computer:~$ /opt/jabref/lib/runtime/bin/java --help
Picked up _JAVA_OPTIONS: -Djava.util.prefs.userRoot=/home/rolandog/.config/java
...

Shell script

Inspecting the shell script:

user@computer:/$ cat /opt/jabref/lib/runtime/bin/JabRef
#!/bin/sh
SCRIPT_NAME=$(basename "$0")
APP_NAME=${SCRIPT_NAME%.sh}

DIR="${0%/*}"



"$DIR/java" $CDS_JVM_OPTS -p "$DIR/../app" -m org.jabref/org.jabref.gui.JabRefLauncher "$@"

I don't know if the module path -p "$DIR/../app" is correct; here is an abridged version of the output of tree:

user@computer:/$ tree /opt/jabref/
/opt/jabref/
├── bin
│   └── JabRef
└── lib
    ├── app
    │   └── JabRef.cfg
    └── runtime
        └── bin
            ├── JabRef
            ├── JabRef.bat
            └── java

Wouldn't "$DIR/../app" point to /opt/jabref/lib/runtime/app instead of /opt/jabref/lib/app? This may be a different bug, though.

Manually launching

Inspecting the shell script's command:

"$DIR/java" \
$CDS_JVM_OPTS \
-p "$DIR/../app" \
-m org.jabref/org.jabref.gui.JabRefLauncher \
"$@"

If I'm interpreting the shell script correctly, it would expand to the following values (if I set the $CDS_JVM_OPTS environment variable, or I manually include the -Djava.util.prefs.userRoot=/home/rolandog/.config/java option). However, as I'm not sure what are the arguments passed to the script, I'm leaving "$@" as blank for the moment:

/opt/jabref/lib/runtime/bin/java \
-Djava.util.prefs.userRoot=/home/rolandog/.config/java \
-p /opt/jabref/lib/runtime/bin/../app \
-m org.jabref/org.jabref.gui.JabRefLauncher

Here's the output of running the previous command:

rolandog@computer:~$ /opt/jabref/lib/runtime/bin/java \
-Djava.util.prefs.userRoot=/home/rolandog/.config/java \
-p /opt/jabref/lib/runtime/bin/../app \
-m org.jabref/org.jabref.gui.JabRefLauncher
Picked up _JAVA_OPTIONS: -Djava.util.prefs.userRoot=/home/rolandog/.config/java
Feb 20, 2022 12:15:28 PM com.sun.javafx.application.PlatformImpl startup
WARNING: Unsupported JavaFX configuration: classes were loaded from 'module org.jabref.merged.module', isAutomatic: false, isOpen: true
2022-02-20 12:15:28 [JavaFX Application Thread] org.jabref.logic.net.URLDownload.bypassSSLVerification()
WARN: Fix SSL exceptions by accepting ALL certificates
Feb 20, 2022 12:15:28 PM java.util.prefs.FileSystemPreferences$1 run
INFO: Created user preferences directory.
2022-02-20 12:15:28 [JavaFX Application Thread] org.jabref.migrations.PreferencesMigrations.upgradeStoredBibEntryTypes()
INFO: Migrating old custom entry types.
2022-02-20 12:15:29 [JavaFX Application Thread] org.jabref.gui.theme.ThemeManager.updateThemeSettings()
INFO: Not updating theme because it hasn't changed
2022-02-20 12:15:29 [JavaFX Application Thread] org.jabref.gui.theme.ThemeManager.updateThemeSettings()
INFO: Theme set to Theme{type=DEFAULT, name=''} with base css StyleSheet{jrt:/org.jabref/org/jabref/gui/Base.css}
Feb 20, 2022 12:15:30 PM com.sun.javafx.css.StyleManager loadStylesheetUnPrivileged
WARNING: Resource "" not found.

And changing "$DIR/../app" to "$DIR/../../app" resulted in a line-by-line identical output.

However... there are some good news to report here!

The good news is that no $HOME/.java/ directory was created... The bad news is that a .java dir was created inside $XDG_CONFIG_HOME/java (in my case /home/rolandog/.config/java/.java/ was created. This confirms that maybe there could be a bug, but I'm not sure if it's JabRef's or if it's an upstream (Java) bug.

Launcher

Not all is good news, however. Opening JabRef with the regular launcher also has its issues... it creates $HOME/.java, in spite of $XDG_CONFIG_HOME/java and $XDG_CONFIG_HOME/java/.java existing (and the proper environment variables being set).

I decided to check the syslog, and here's the output:

user@computer:~$ tail -f /var/log/syslog | grep -i jabref
Feb 20 12:45:14 computer jabref-JabRef.desktop[32960]: Feb 20, 2022 12:45:14 PM com.sun.javafx.application.PlatformImpl startup
Feb 20 12:45:14 computer jabref-JabRef.desktop[32960]: WARNING: Unsupported JavaFX configuration: classes were loaded from 'module org.jabref.merged.module', isAutomatic: false, isOpen: true
Feb 20 12:45:14 computer jabref-JabRef.desktop[32960]: 2022-02-20 12:45:14 [JavaFX Application Thread] org.jabref.logic.net.URLDownload.bypassSSLVerification()
Feb 20 12:45:14 computer jabref-JabRef.desktop[32960]: WARN: Fix SSL exceptions by accepting ALL certificates
Feb 20 12:45:14 computer jabref-JabRef.desktop[32960]: Feb 20, 2022 12:45:14 PM java.util.prefs.FileSystemPreferences$1 run
Feb 20 12:45:14 computer jabref-JabRef.desktop[32960]: INFO: Created user preferences directory.
Feb 20 12:45:14 computer jabref-JabRef.desktop[32960]: 2022-02-20 12:45:14 [JavaFX Application Thread] org.jabref.migrations.PreferencesMigrations.upgradeStoredBibEntryTypes()
Feb 20 12:45:14 computer jabref-JabRef.desktop[32960]: INFO: Migrating old custom entry types.
Feb 20 12:45:15 computer jabref-JabRef.desktop[32960]: 2022-02-20 12:45:15 [JavaFX Application Thread] org.jabref.gui.theme.ThemeManager.updateThemeSettings()
Feb 20 12:45:15 computer jabref-JabRef.desktop[32960]: INFO: Not updating theme because it hasn't changed
Feb 20 12:45:15 computer jabref-JabRef.desktop[32960]: 2022-02-20 12:45:15 [JavaFX Application Thread] org.jabref.gui.theme.ThemeManager.updateThemeSettings()
Feb 20 12:45:15 computer jabref-JabRef.desktop[32960]: INFO: Theme set to Theme{type=DEFAULT, name=''} with base css StyleSheet{jrt:/org.jabref/org/jabref/gui/Base.css}
Feb 20 12:45:16 computer jabref-JabRef.desktop[32960]: Feb 20, 2022 12:45:16 PM com.sun.javafx.css.StyleManager loadStylesheetUnPrivileged
Feb 20 12:45:16 computer jabref-JabRef.desktop[32960]: WARNING: Resource "" not found.
Feb 20 12:45:17 computer JabRef[32960]: XSetErrorHandler() called with a GDK error trap pushed. Don't do that.
Feb 20 12:45:18 computer jabref-JabRef.desktop[32960]: Feb 20, 2022 12:45:18 PM com.sun.javafx.css.StyleManager loadStylesheetUnPrivileged
Feb 20 12:45:18 computer jabref-JabRef.desktop[32960]: WARNING: Resource "" not found.
Feb 20 12:45:49 computer systemd[2505]: app-gnome-jabref\x2dJabRef-32960.scope: Deactivated successfully.
Feb 20 12:45:49 computer systemd[2505]: app-gnome-jabref\x2dJabRef-32960.scope: Consumed 12.800s CPU time.

I have two theories to test to make the launcher properly work:

Exec

Inspecting the launcher(s) (I imagine the installer copies the .desktop file from /opt/jabref/lib to /usr/share/applications):

user@computer:~$ cat /usr/share/applications/jabref-JabRef.desktop
[Desktop Entry]
Name=JabRef
GenericName=BibTeX Editor
Comment=JabRef is an open source bibliography reference manager. The native file format used by JabRef is BibTeX, the standard LaTeX bibliography format.
Exec=/opt/jabref/bin/JabRef
Icon=/opt/jabref/lib/JabRef.png
Terminal=false
Type=Application
MimeType=text/x-bibtex
Categories=Office;
Keywords=bibtex;biblatex;latex;bibliography
StartupWMClass=jabref

I notice it's using /opt/jabref/bin/JabRef and not /opt/jabref/lib/runtime/bin/JabRef. I will try editing the Exec path to the latter, and see if there are differences in the outcome when compared to manually launching versus using the launcher.

Non-interactive non-login shell environment variables

I will test later by setting the environment variable _JAVA_OPTIONS to DEFAULT=-Djava.util.prefs.userRoot=@{HOME}/.config/java inside /etc/security/pam_env.conf, because I think this may have to do with non-interactive non-login shell scripts.

Edit: formatting

[rolandog]

Reporting back...

Modifying the Exec path launched JabRef, but it still created $HOME/.java.

Setting the environment variables with PAM worked properly (even got a jabref-JabRef.desktop[6904]: Picked up _JAVA_OPTIONS: -Djava.util.prefs.userRoot=/home/rolandog/.config/java in the syslog). But, $XDG_CONFIG_HOME/java/.java was still created.

[rolandog]

Ok, after testing with a different app, I can conclude that this isn't a JabRef-specific bug, since other java-based apps also create a .java directory at the specified target directory.

I'll see if I can report it upstream, though the fix would probably have to take into account Hyrum's law, and check if there's a .java dir inside the target java.util.prefs.userRoot before creating a .userPrefs dir inside it.

Thank you very much for the pointer to the Oracle docs!

[Siedlerchr]

Thanks for the writeup! Thanks for the confirmation that the .java is created by JDK by default. You can report bugs in java here: https://bugreport.java.com/bugreport/

[rolandog]

Thanks for the pointer, I didn't know where to start looking that up, as I'm not that familiar with Java.

[rolandog]

So, one of the requirements in order to submit a bug was to test with the latest early access version of Java. I created a backup copy of /opt/jabref and replaced the available files in /opt/jabref/lib/runtime with the files from openjdk-19-ea+10_linux-x64_bin, but I'm getting the following output:

user@computer:~$ /opt/jabref/lib/runtime/bin/java -Djava.util.prefs.userRoot=$XDG_CONFIG_HOME/java -p /opt/jabref/lib/runtime/bin/../app -m org.jabref/org.jabref.gui.JabRefLauncher
Picked up _JAVA_OPTIONS: -Djava.util.prefs.userRoot=/home/rolandog/.config/java
Error occurred during initialization of boot layer
java.lang.module.FindException: Module org.jabref not found

After googling a bit, it seems like this may have to do with how the classes are defined?

In any case, I'm not very knowledgeable yet in how to build java programs from source, and this seems to be a known, though not very documented, behavior (found while trying to find if this was already reported upstream, which it doesn't seem to be the case).

So I guess I'll leave it alone for now.