Jabref: Jabref rendering problems with GTK Look and Feel on Linux and OpenJDK

[nswitte]

My system:
Ubuntu 15.10

Linux version 4.2.0-18-generic (buildd@lgw01-38) (gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2) ) #22-Ubuntu SMP Fri Nov 6 18:25:50 UTC 2015 (Ubuntu 4.2.0-18.22-generic 4.2.3)

java version "1.7.0_91"
OpenJDK Runtime Environment (IcedTea 2.6.3) (7u91-2.6.3-0ubuntu0.15.10.1)
OpenJDK 64-Bit Server VM (build 24.91-b01, mixed mode)

All three versions of Jabref hang (after starting up OK, reading the database and selecting an entry), say when editing a file link or some other operation. Once this happens all buttons are inactive and I have to kill the process. This started today after Java got upgraded, so maybe this has something to do with it. Previously this was not a problem. I have looked at the FAQ but it doesn't seem relevant.

Any solutions would be really handy as I am pretty reliant of Jabref to manage my bibliographies.

Thanks, Nicholas

[koppor]

We did not change any code in JabRef 2.10 since its release in March 2014. Therefore, this should be an JRE issue. Could you downgrade your JRE? As soon as you know the JRE version where JabRef runs, could you report this as an issue to the ubuntu bug tracker?

Meanwhile, you can try Java8 and the latest build. I am afraid, that this won't succeed, too.

The only thing, that currently helps is to upgrade to Oracle's JRE using the oracle-java8-installer.

[matthiasgeiger]

At least 2.11 should also work with OpenJDK 8 - see #168.

[pviotti]

As reported above, I too use Ubuntu 15.10, and I have tried both the version in the repository (2.10) and the last stable version available (2.11.1).

• Version 2.10 using java 1.7 (openjdk): cannot test it because even if I change the default java from 1.8 to 1.7 system wide, it uses java 1.8 (this should probably be a separate bug..)
• Version 2.10 using java 1.8 (openjdk): sometimes it hangs on the splashscreen, sometimes it starts up and load the last file I edited, but as soon as I try to click around or open another file, it hangs (with no errors printed on the console, except warnings such as "Could not get key binding for "Open folder"")
• Version 2.11.1 (jar) using java 1.7 (openjdk): starts up and load the last file I edited, but as soon as I try to do something like clicking around or opening another file, it hangs
• Version 2.11.1 (jar) using java 1.8 (openjdk): starts up and load the last file I edited, but as soon as I try to open another file, it hangs (more precisely, it hangs as I click on a folder in the standard java open file dialog window)

So right now I don't know any trivial way of using JabRef on the last version of Ubuntu.
Thanks,
Paolo

[matthiasgeiger]

:disappointed:

Have you tried it with oracle-jdk?

[pviotti]

Nope, unfortunately I don't have time to install it (it's not in the Ubuntu repositories) nor to do other tests..
(Anyway, OpenJDK is the official reference implementation of Java SE, so you should use it to develop JabRef... :wink: )

[simonharrer]

All current developers of JabRef use Windows. I have not found an openjdk implementation that can be installed on windows. Do you have any pointers for us?

[pviotti]

Uh, I wasn't aware that openjdk is only available for Linux :confused: so much for "write once, run everywhere"
Still, since I reckon Linux is widely used by researchers, I suggest you should pay more attention to its compatibility.
Anyway, thanks for the work you guys did and do on JabRef: it's a very useful piece of software. :smiley:

I'll try to run it with oracle-jdk as soon as I can...

[peebz]

The same problem has been happening to me today. I've just submitted a report to Ubuntu bug tracker.

[simonharrer]

Hm, you could try to run the jar via java -jar jabref.jar (jar can be downloaded directly from our mirrors) and then give us any stacktraces for debugging purposes.

[pviotti]

No stacktraces nor errors get printed.
So as suggested here I tried to run the jar (2.11.1, with openjdk 7) and then get a thread dump using jstack.
I enclose two log files: one before it gets stuck, and one after.
jabref_jstack-before.txt
jabref_jstack-after.txt

In short, after it gets stuck, some thread in charge of painting some graphical component appears to be in BLOCKED state.
So it seems to me that this is a (major) bug of the GTK look&feel implementation.
Besides, for the record, recently I had similar problems with other java software such as Freemind and Netbeans.

[koppor]

For the record 1520294 is Ubuntu's bug number.

[simonharrer]

In Preferences -> Advanced you could change the look and feel if you are able to get there. Maybe this helps.

[pviotti]

Indeed it works. I switched to MetalLookAndFeel, restarted, and it doesn't get stuck anymore (using any java version).
Great, thanks for the hint!
(Maybe don't mark this as solved so that people with this problem can come here and read about the workaround - waiting for a proper fix..)

[peebz]

Fantastic! Just done the same and it works :-) Many thanks Simon!

PS. Please move Jabref off Sourceforge. It is so dodgy nowadays...

[simonharrer]

Maybe we should change the default for linux based systems.

[JackKelly]

I was having a very similar problem. I tried lots of things in vane (I tried using openjdk-6, 7 and 8; I tried doing apt-get purge on everything relating to Java on my system and deleting ~/.java and then re-installing openjdk and JabRef etc... but jabref still crashed). I'm on Ubuntu 15.10.

Before I found this bug report (i.e. before I saw that a work-around is to change to MetalLookAndFeel), the one thing that I found to work was to edit /etc/java-7-openjdk/accessibility.properties and comment out assistive_technologies=org.GNOME.Accessibility.AtkWrapper. I just thought I'd mention this in case it's useful for debugging!

Thanks to all the JabRef devs. It really is a great bit of software!

I'd definitely recommend keeping an eye on how well JabRef works on Linux. As others have said, there are probably quite a few researchers who use Linux pretty much exclusively (like me).

[simonharrer]

Thank you for the nice words about JabRef! As this is an open source project, we do welcome help. At the moment we are lacking a developer who uses Linux as his main operating system. :)

[matthiasgeiger]

... and developers using Macs are also welcome...

... and we would even accept help from people who are using Windows :stuck_out_tongue_winking_eye:

[oscargus]

...and female developers... (so "her operating system" is also OK.)

[andim]

Thanks for the work around of changing the Look and Feel. I agree with others that it would be nice to have it work out of the box on Linux again! It did take me some unproductive time trying to figure out what went wrong before I found this issue.

[oscargus]

For the record:

JabRef works out of the box on CentOS 6.7, kernel 2.6.32-573.3.1.el6.x86_64, GNOME 2.28.2.

java version "1.8.0_65"
Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.65-b01, mixed mode)

Not sure if this is pure luck (as I do not administer the computer myself).

I think one problem here is that "Linux" is rather badly defined... Without knowing any details it appears as if the major source of the problem is that parts of OpenJDK are not thread-safe. A patch is proposed that probably would solve the problem (since August), but OpenJDK is not keen on applying it.

[matthiasgeiger]

@oscargus What is the default look and feel used with this CentOS machine?

[oscargus]

Assuming that JabRef reports the correct thing in the preference dialog (or is there a better way?): com.sun.java.swing.plaf.gtk.GTKLookAndFeel

[ocli5568]

Confirmed the look and feel value was the problem on Ubuntu 15.10:

openjdk version "1.8.0_66-internal"
OpenJDK Runtime Environment (build 1.8.0_66-internal-b17)
OpenJDK 64-Bit Server VM (build 25.66-b17, mixed mode)

Preferences should be in ~/.java/.userPrefs/net/sf/jabref/prefs.xml. There should be a key called lookAndFeel with the GTK theme set (line 94), change the line to:
<entry key="lookAndFeel" value="javax.swing.plaf.metal.MetalLookAndFeel"/>
or:
<entry key="lookAndFeel" value="javax.swing.plaf.metal.SynthLookAndFeel"/>

p.s. @oscargus, The GTKLookAndFeel failed on Ubuntu 15.10 with java 1.7.0_95 and java 1.8.0_66.

[stefan-kolb]

@simonharrer You remember when we tried this in Stuttgart togetehr with a student? Do you remember which algorithm we suggested to switch from the LAF to metal? I thought we found the problem or at least a check when we need to switch?

[simonharrer]

Hm, I do not recall it perfectly, but it was something like:

• check OS
• if on linux, set to MetalLookAndFeel as default
• a user can later change to another look and feel, but this is then up to the user

[stefan-kolb]

I think it wasn't just if on linux but a certain special case...

[kratman]

I have been having this bug for a while, but I could not even launch JabRef in Ubuntu. Even after changing the prefs.xml file. On my system it would almost always freeze at the splash screen, which then would block my view of terminals and other windows. I would have to "killall java" to get rid of the splash screen.

What did seem to help was deleting my .java directory (to wipe all Java/JabRef config information) then opening it again. When I reopened JabRef, the default look and feel was GTK (it was Plastic3D before) and I could change the look and feel settings. I can now open and reopen JabRef without freezing.

This suggests that the problem may be related to older config settings that are not being corrected when Ubuntu updates JabRef and/or Java. Of course this work-around (wiping all Java settings) is only an option for me since on my machine only JabRef requires java.

Unfortunately, I did not save my old config files before I started trying to fix things. So I cannot really dig into this further. I do know that uninstalling and reinstalling JabRef let me get past the splash screen once, then it would freeze again. I even removed JabRef with the "completely remove including config files" option in the synaptic package manager, but this does not delete the local settings in the user's home directory (i.e. the .java directory).

Hopefully this helps.

[zesaro]

My problem in Stuttgart was caused when using OpenJDK and GTKLookAndFeel. In my case when I want to open a file and navigate through the filechooser the GUI freezes. When using the Oracle JDK it works normal. Another way to solve it is to use MetalLookAndFeel with OpenJDK.

[sneumann]

Hi, I can confirm that commenting out assistive_technologies
in /etc/java-8-openjdk/accessibility.properties mentioned above by JackKelly
fixes the lockup on Ubuntu 16.04 with openjdk-8. Yours, Steffen

[simonharrer]

Hm, maybe we can do this as part of the installer on ubuntu?

[stefan-kolb]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813143

[mlep]

Does #1116 mean JabRef 3.3 works safely with OpenJDK?

[pirlite2]

In response to a request by Frédéric Darboux "Which "Look and Feel" are you using? (this is displayed in Options -> Preferences -> Appearance) Could you confirm (or not) that JabRef 3.3 does not work with the GTK Look and Feel under Linux? "

I have tried changing from the default javax.swing.plaf.metal.MetalLookAndFeel to com.jgoodies.looks.plastic.Plastic3DLookAndFeel; JabRef restart OK but I cannot see any difference in the look-and-feel. When I select com.jgoodies.looks.windows.WindowsLookAndFeel, the restart announces that the specified LaF cannot be found and JabRef is reverting to the default. There is no GTK Look and Feel in the drop-down box.

Hope this helps. I am using Linux Mint 17.3 + OpenJDK 8.

[stefan-kolb]

@mlep No, it just uses the Metal LookAndFeel by default and therefore (hopefully) prevents the current issues. If you change to another LAF you are at the same point as before.

[stefan-kolb]

We also cannot confirm that GTK LAF does not work for anyone, but there are obviously problems for some...

[pirlite2]

"We also cannot confirm that GTK LAF does not work for anyone, but there are obviously problems for some..." Sorry, but that doesn't make any sense!

Further to my earlier post, I have had a look at changing the LaF on Windows. I cannot see any difference between any of the LaFs! (Much like Linux.) What changes should I expect to see if this working as intended?

[stefan-kolb]

Sorry, but my response wasn't targeted at your question.

Regarding your question:
I don't know why you cannot see any difference between LAFs. Imho, this is another issue that need not to be related with the topic here. Maybe you don't have the LAF inside the classpath? Normally it should not be displayed if so, so maybe it's a bug. I think this needs to be discussed in a separate issue.

[stefan-kolb]

This is out of our hands. Closing this for now, should be retrievable for reference anyway.