Package Details: jabref 4.1-2

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: 166
Popularity: 0.308780
First Submitted: 2012-06-07 22:47
Last Updated: 2018-04-10 17:29

Latest Comments

arrhenius commented on 2018-01-21 15:36

" fails checksum validity check."

Solved by removing ~/.cache/pacaur/jabref

jbarnett commented on 2018-01-15 23:50 fails checksum validity check.

Rhinoceros commented on 2018-01-08 09:30

That seems logical to me, too.

Bevan commented on 2018-01-08 09:28

Rhinoceros: That makes sense, yes. Hm... I could require java-openjfx=8 here since jabref currently only works with Java 8 anyway.

Rhinoceros commented on 2018-01-08 09:24

Oh yeah… I can see that now. I have no idea. Ahhh… perhaps it's because jre provides java-openjfx=9, and I already had that installed?

Bevan commented on 2018-01-08 07:53

Rhinoceros: How did you manage to install this package without installing java-openjfx first? It is a dependency.

Rhinoceros commented on 2018-01-08 04:00

The new version failed to start on my system with:

Error: Could not find or load main class org.jabref.JabRefMain

I'm using java-8-openjdk. After installing java-openjfx, jabref could again launch.

dvzrv commented on 2018-01-01 11:20

@Bevan: it was the license file. Deleted and reinstalled.

pryre commented on 2018-01-01 07:37

I was also having some issues building the package. Cleaned out the cache of my AUR helper, then had no issues installing it. Might have something strange going on with scrap files from between versions, but it was a simple fix.

Bevan commented on 2017-12-30 11:04

curl 2>/dev/null | sha256sum : d0a8248eeaafc526f1137703fdc5aac1c8fae106f94c4bef56e3650e2c4c73a7

... which is exactly the checksum given in the PKGBUILD. Even in upstream's master branch the file was not touched since May:

billypilgrim and dvzrv: Maybe you have still an old file from JabRef 3 lying around? If necessary, please download the file manually and check where the difference is coming from.

billypilgrim commented on 2017-12-30 10:19

This package is no longer building as has changed

Bevan commented on 2017-12-29 14:17

dvzrv: They do for me. I just rechecked. Maybe one of the downloads failed / got corrupted?

dvzrv commented on 2017-12-29 14:01

@Bevan: The checksums don't match

j0hannes commented on 2017-12-27 17:17

If you use the current version (4.1-1) be sure to always have a backup of your bib files as it randomly overwrites entries when editing.

Huulivoide commented on 2017-12-10 15:13

Java 9 support would be nice. Just need to add '--add-modules java.xml.bind' to the command line if Java 9 is used.

Bevan commented on 2017-11-25 18:48

Since people keep commenting without reading through the comments before, here's a summary on why this is not updated to JabRef 4.0:

- JabRef 4.0 has a series of serious bugs (won't start, won't stop, will eat gigabytes of memory, ...).
- Most of these bugs are fixed in git by now but no release includes them yet.
- Applying these patches to this package would require everyone to rebuild the JAR file and install several build-time dependencies.
- People wanting to build the JAR from current git can use the jabref-git package here in AUR.
- There is no need to duplicate jabref-git in this package, it is already there. Use it.
- If you really really want to install JabRef 4.0 without these patches, take this PKGBUILD:
- You can also download a prebuilt jar file from
- Unfortunately these jar files are not archived which is why I cannot use them here.

Please refrain from asking why this has not been updated yet, why I do not apply patches from git, or when I will update this package. I will likely just ignore these questions in future.

d4muck commented on 2017-11-25 10:33

@Bevan when will you update to v4?

As I understood you wrote in your pinned comment that you solved both issues

Bevan commented on 2017-11-13 10:28

hseara: This looks to me like another instance of JabRef is running but has somehow crashed. Could you check for any running java instances with ps and kill them if they relate to jabref? Or, alternatively, reboot.

hseara commented on 2017-11-13 10:20

@Bevan Thanks your suggestion.

If you cannot open jabref and you get the following message:

11:16:21.281 [AWT-EventQueue-0] WARN org.jabref.logic.remote.server.RemoteListenerServerLifecycle - Port is blocked Address already in use (Bind failed)
11:16:21.357 [AWT-EventQueue-0] INFO org.jabref.JabRefMain - Arguments passed on to running JabRef instance. Shutting down.

check for open instances of jabref and kill them.

Note: In multi-user system environments check the following issue: (

Rhinoceros commented on 2017-10-25 10:29

@Bevan Ah, fair enough. Thank you for the explanation.

Bevan commented on 2017-10-25 08:44

Rhinoceros: Currently this package uses a prebuilt jar-file. To apply the changes, this would have to be changed to build the jar-file from source on PKGBUILD. That is possible for sure, but then again there is also a jabref-git package here in the AUR which pretty much does exactly that.

By the way: There are also prebuilt jar-files for the current git revision, but as far as I can see they only keep the most recent version on the server, so we cannot just use that:

Rhinoceros commented on 2017-10-25 00:52

@Bevan Could you possibly backport the fixes into 4.0 instead? That's what normally happens on "official" Arch packages. You can get the fixes in patch format by appending `.patch` to the github urls that you list in your comment.

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;