Package Details: jabref 3.8.2-3

Git Clone URL: (read-only)
Package Base: jabref
Description: GUI frontend for BibTeX, written in Java
Upstream URL:
Licenses: MIT
Submitter: Allan
Maintainer: Bevan
Last Packager: Bevan
Votes: 165
Popularity: 3.332541
First Submitted: 2012-06-07 22:47
Last Updated: 2017-08-23 22:26

Pinned Comments

Bevan commented on 2017-10-04 16:51

I have an update for JabRef 4.0 but I have serious issues with this version:
* JabRef does not quit, it stays active after exit waiting for some futex.
* On one machine JabRef needs many minutes to start, checking for duplicate aliases

If you want to try the new package, you can get it from here:

I will only push it to the AUR as soon as those major issues are solved.

Update: Problem no. 1 is now solved in git, problem no. 2 was a local issue with leftover data from older JabRef versions.

Latest Comments

Zebra commented on 2017-10-07 17:16

Bevan: Reasonable enough. Thanks for maintaining!

Bevan commented on 2017-10-07 14:39

Zebra: Thanks for the feedback! The issue of not properly exiting is now fixed in git by the following three commits:

I'd like to wait for a release including these fixes before pushing JabRef 4 to AUR.

The other issue of long starting time seemed to be an issue with leftover configuration from an older JabRef version, I could fix it by cleaning that up.

Ogion: Good point, JabRef 4 uses JavaFX now so that package is required. I will add it as a dependency.

Ogion commented on 2017-10-07 13:53

The aur Package from your github link works just fine for me, except for one thing: I had to install `java-openjfx` from the repo, before JabRef would actually run. You should probably add that to the Depends.

Zebra commented on 2017-10-07 10:44

Bevan: I testet your package just now (4.0.1) and cannot reproduce your issues. Stops at once. start up time is 3.5 seconds max.

Bevan commented on 2017-10-04 16:51

I have an update for JabRef 4.0 but I have serious issues with this version:
* JabRef does not quit, it stays active after exit waiting for some futex.
* On one machine JabRef needs many minutes to start, checking for duplicate aliases

If you want to try the new package, you can get it from here:

I will only push it to the AUR as soon as those major issues are solved.

Update: Problem no. 1 is now solved in git, problem no. 2 was a local issue with leftover data from older JabRef versions.

Bevan commented on 2017-08-24 08:14

koppor: Thanks for the updates! The new package release now explicitly calls java 8. I also looked into the .desktop file and the start script. The first has slightly different entries (Icon and StartupWMClass), so we cannot use it as is. But I changed the one provided by this package to be as close as possible. The start script provided here is very specific to Arch Linux as it calls archlinux-java to find out what JVM was selected by the user. So I'm not sure how valuable this is for upstream. It could be a starting point for a more universal start script that supports multiple distributions though.

koppor commented on 2017-08-18 08:26

JabRef will soon release version 4.0, which depends on JavaFX. I think, one has only to add "java-openjfx" to the list of dependencies.

The java-runtime should be set to precisely 8, as JabRef currently does not run at Java9:

koppor commented on 2017-08-18 08:24

JabRef now also tries to maintain a .desktop file. See Maybe, that file can be used? We can also place it somehwere else in the src tree. Maybe directly at buildres/?

The JabRef team is also often asked to provide a (see Maybe, you could provide your as pull request to JabRef's main repository? I would propose the scripts/ folder as the location.

n-st commented on 2017-06-03 20:40

JabRef has recently had its license updated. The PKGBUILD contains the checksum of the v3.8.2 license, but downloads the license from the master branch (currently v4.x beta), so the checksum test fails.

Try this patch as a fix:

Bevan commented on 2017-02-03 14:14

@Rhinoceros: Thanks a lot! :)

Rhinoceros commented on 2017-02-02 23:30

Thanks @Bevan. Here's a replacement to that works for me. It checks if java 8 is selected as the default java, and if not, reverts to your original script of selecting the alphabetically-last java. This *should* keep everyone happy! :)


if [[ "$(archlinux-java get)" == java-8-* ]]
exec /usr/bin/java -jar /usr/share/java/jabref/JabRef-VERSION.jar "$@"
# Force usage of latest java version
JVM_PATH=$(find /usr/lib/jvm/* -maxdepth 0 -type d | sort | tail -n1)
exec $JVM_PATH/jre/bin/java -jar /usr/share/java/jabref/JabRef-VERSION.jar "$@"

Bevan commented on 2017-02-02 21:37

@Rhinoceros: I guess you are right. It's difficult to find something here to make everybody happy but I will try soon.

Rhinoceros commented on 2017-01-23 00:16

It looks like selects the latest version of java installed, rather than following the default, as set in archlinux-java. This can cause problems, because it selects the buggy version in my case [1]. I understand that jabref needs java 8, not java 7, but it might be worth following archlinux-java if a version 8 is selected, otherwise defaulting to one of the version 8s. Hard-coding the version seems wrong IMO.


danmc commented on 2016-12-15 15:57

The license has changed to MIT since version 3.6.

Bevan commented on 2016-07-16 09:23

@antony: This issue occured when there was already a "src" directory lying around from the last build.

I now changed the PKGBUILD to only extract from the JAR what is needed which solves this issue.

anntzer commented on 2016-07-16 01:16

Cuurently fails to build:

==> Extracting sources...
-> Extracting JabRef-3.5.jar with bsdtar
com/: Can't replace existing directory with non-directory
META-INF/maven/org.apache.httpcomponents/httpcore-nio/: Can't replace existing directory with non-directory
bsdtar: Error exit delayed from previous errors.
==> ERROR: Failed to extract JabRef-3.5.jar
:: failed to build jabref package(s)

Bevan commented on 2016-07-15 22:20

@chicomag: The .jar file needs to be extracted because this is where we get the application icon get from, so extracting is actually intended. I don't see any disadvantage of this, because we package only what is needed (jar file, icon, start script, desktop file).

chicomag commented on 2016-07-15 22:00

Please, add noextract=("JabRef-${pkgver}.jar") to the PKGBUILD, because makepkg is extracting the file, and this is not intended.

koppor commented on 2016-06-05 17:43

BibLaTeX mode is a file-based mode now. Switch the mode using File -> "Switch to BibLaTeX mode".

See also blog entry "April 19, 2016 – Release of JabRef 3.3" on (Sorry, currently no deep links possible).

Bevan commented on 2016-04-19 20:36

@Moneysac: Will push the new version in a moment but please use the "flag out-of-date" function in future.

Regarding the BibLaTeX mode: I think the option just moved. In Preferences->General you can change the standard mode from BibTeX to BibLaTeX.

Moneysac commented on 2016-04-19 11:25

Version 3.3 is available. This package does not provide the biblatex mode which is important for online references.

anntzer commented on 2016-02-04 08:58 should just force Java 8 (like the jabref-git package does:, otherwise jabref will fail to start on environments where Java 7 is the default.

zzjjzzgggg commented on 2016-01-11 13:54

It seems that the 3.2 version has been released. Shall we update this package now?

gbc921 commented on 2015-12-31 10:35

The link is working now. The problem seemed to on Sourceforge, that did not have any mirrors available at that time.

gbc921 commented on 2015-12-31 00:13

Jabref source link on sourceforge is broken (even trying to download through the browser redirects to the initial page).
I'm not sure if it is related to Sourceforge or upstream, will contact dev and post any news here.

Francois_B commented on 2015-12-17 14:03

That sounds. I tried to remove java7 before asking you but I still have few packages that depends on java7, and one critical for me. They may work with java8. I'll contact the maintainers to check that.

note for others, small typo in the command path: /usr/lib/jvm/java-8-openjdk/jre/bin/java -jar /usr/share/java/jabref/JabRef-3.0.jar

Thank you.

Bevan commented on 2015-12-16 14:58

@Francois_B: It looks to me like you try running it with an older Java version. Please try running it by executing:
/usr/lib/jvm/java-8-openjdk/bin/java -jar /usr/share/java/jabref/JabRef-3.0.jar

For a permanent solution you may copy this into a custom start script in /usr/local/bin. But it may need adjustments on future JabRef updates.

A clean solution would probably be to remove Java 7 from your system instead, if you do not need it for some reason.

Francois_B commented on 2015-12-16 14:51

I have this error:

$ jabref
Exception in thread "main" java.lang.UnsupportedClassVersionError: net/sf/jabref/JabRefMain : Unsupported major.minor version 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(
at Method)
at java.lang.ClassLoader.loadClass(
at sun.misc.Launcher$AppClassLoader.loadClass(
at java.lang.ClassLoader.loadClass(
at sun.launcher.LauncherHelper.checkAndLoadMain(

Anybody has an idea?

anntzer commented on 2015-12-15 19:34

In order to make this work even when the default Java installed is Java7, you may want to apply the following solution to

Bevan commented on 2015-12-01 10:08

@etienne: Ah, yet another Java application that needs this hack. Update will come in a minute. Thanks! :)

etienne commented on 2015-12-01 10:06

On Gnome Shell the starter of Jabref is not the same as the one of the opened application, so I get two Jabref symbols in the starter panel when running. To avoid this, I simply had to add the line


to my jabref.desktop. To keep the change I copied /usr/share/applications/jabref.desktop to ~/.local/share/applications/ and applied the modification there.

Bevan commented on 2015-12-01 09:50

It seems like JabRef 3 deliberately requires Java 8:

I will change the dependencies accordingly. If people would rather stick with Java 7 they can get the old PKGBUILD for JabRef 2.11.1 here:

bayone commented on 2015-12-01 01:30

@Bevan: jabref 3.0 crashes with jre7-openjdk. I had to switch to jre8-openjdk to get it to work. It also says on sourceforge it requires java 1.8 (jre8).

Bevan commented on 2015-07-16 20:14

@torta: seems to have problems with their load balancing at the moment. You may replace the first entry in source by to work around this temporarily.

torta commented on 2015-07-16 20:06

@magno, i'am having the same problem. How do you solve it?

==> Validando las fuentes con sha1sums...
JabRef-2.10.jar ... HA FALLADO ... Aprobado
jabref.desktop ... Aprobado
==> ERROR: ¡Uno o más archivos no superaron el control de validación!
==> ERROR: Makepkg no ha podido compilar jabref.

hseara commented on 2015-07-11 18:12

I had little time to deal with the AUR4 migration lately. Therefore, I do not mind if you want to maintain it from this point on.

Bevan commented on 2015-07-08 12:21

I just migrated this package to AUR4. If the original maintainer (hseara) wants it back I will transfer the ownership back of course. Otherwise I will keep maintaining it.

hseara commented on 2015-02-11 17:27

@magno everything works fine. The problem is in your side

==> Retrieving sources...
-> Downloading JabRef-2.10.jar...
% Total % Received % Xferd Average Speed Time Time Time Current
100 14.5M 100 14.5M 0 0 8937k 0 0:00:01 0:00:01 --:--:-- 26.7M
-> Found
-> Found jabref.desktop
==> Validating source files with sha1sums...
JabRef-2.10.jar ... Passed ... Passed
jabref.desktop ... Passed

magno commented on 2015-02-10 16:54

==> Making package: jabref 2.10-2 (Tue Feb 10 16:52:07 WET 2015)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found JabRef-2.10.jar
-> Found
-> Found jabref.desktop
==> Validating source files with sha1sums...
JabRef-2.10.jar ... FAILED ... Passed
jabref.desktop ... Passed
==> ERROR: One or more files did not pass the validity check!
The build failed.

If checksums are corrected with updpkgsums, the this error:
install: cannot stat ‘images/JabRef-icon-48.png’: No such file or directory

hseara commented on 2014-05-08 06:41

As web search is not required feature to use jabref and to avoid enforcing too many dependencies on installation I have added "gsettings-desktop-schemas" package as an optional dependency. Thanks for the tip, I did not realize as I have whole gnome installed.

anntzer commented on 2014-05-07 22:11

Please add a dependency on gsettings-desktop-schemas, as jabref core-dumps in its absence when trying to perform a web search.

Anonymous comment on 2013-04-05 04:28

users of non reparenting window managers such as dwm edit /usr/bin/jabref and add the line;