"open folder" causes java.lang.NullPointerException: null

JabRef–master–latest.jar (https://builds.jabref.org/master/) as well as version 4.3.1-2 form Arch AUR (https://aur.archlinux.org/packages/jabref/)

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

Right clicking on any entry in any database and selecting “Open folder” results in the NullPointer exception below. The setup experiencing this problem is Arch Linux with i3 window manager and without desktop environment. Hence it could be that there is a dependency to some external SW that is not satisfied. This problem exists over multiple version already (~1y) over different Arch machines I operate. My guess is that there is some unknown dependency that I lack on my systems, which causes “open folder” to silently crash. I would be interested in tracking down what exactly is causing that issue. Might be something very obvious to you guys.

Steps to reproduce the behavior:

1. On Arch Linux + Jabref master latest or Jabref 4.3.1-2 from AUR: open any database where files have associated pdfs in their entires.
2. Right click, “open folder” --> exception below

Log File

10:51:41.270 [JabRef CachedThreadPool] ERROR org.jabref.FallbackExceptionHandler - Uncaught exception occurred in Thread[JabRef CachedThreadPool,5,main]
java.lang.NullPointerException: null
  at org.jabref.gui.desktop.os.Linux.openFolderAndSelectFile(Linux.java:54) ~[JabRef--master--latest.jar:?]
  at org.jabref.gui.desktop.JabRefDesktop.openFolderAndSelectFile(JabRefDesktop.java:171) ~[JabRef--master--latest.jar:?]
  at org.jabref.gui.BasePanel.lambda$null$49(BasePanel.java:348) ~[JabRef--master--latest.jar:?]
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[?:1.8.0_201]
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[?:1.8.0_201]
  at java.lang.Thread.run(Thread.java:748) [?:1.8.0_201]

Used Java version:

java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)

I’m happy to provide further details!

[deepakkumar96]

Now, when user clicks “open folder”, JabRef will try to look whether file browser command(in Preference Tab) is explicitly set by the user or not, If yes then it will execute that command otherwise default behaviour will be applied by checking “DESKTOP_SESSION” environment variable. So Is this solution correct or Do I have to find some other way?

[geekoverdose]

@Siedlerchr now I understand. I neither have nautilus installed nor is my DESKTOP_SESSION set. My suggestion would be:

• in the preferences in external programs give an option for which command is executed when “open folder” is selected. This way on Linux you would not be bound to any specific file browser. You could include the path to the file selected in JabRef as a variable in that command: this way users would be able to choose where in the command the path to the selected file is used. This is similar to how e.g. Kile handles external programs like file browsers, pdf vieweres, etc, should you be familiar with Kile.

• in situations where you need to anyway rely on those external environment variables and external programs to be present, maybe make the exception descriptive. I just realized with the code above that setting my DESKTOP_SESSION and installing Nautilus or similar might have solved the problem 😃

• I would not recommend on hard coding any terminal - this would lead to similar issues as with file browsers (people used different terminals). Giving users choice - maybe with reasonable defaults, to this I agree - would cover more of those corner cases in my opinion.