Eclipse: JavaHL



Get the right version!

Before explaining what JavaHL is, it is important that you know what version you need for the version of Subclipse you are using. JavaHL is part of Subversion, so it's version matches that of the Subversion command line client you have installed. Each Subclipse version typically only supports a single Subversion client version (due to API differences). Make sure you get the right version of JavaHL for your Subclipse version.

Current Versions

Subclipse Version

SVN/JavaHL Version

















This is the most complicated because there are so many distributions.

CollabNet provides a client RPM for Red Hat that includes JavaHL ( In my experience, this RPM works on other Linux distributions. On RPM-based distributions like CentOS or Suse, it should just be a matter of installing the RPM. On Debian-based systems, I was able to use the alien package to install the RPM.

Of course many Linux distributions, such as Ubuntu, do a good job of providing up to date Subversion packages, and most of these now provide JavaHL as well. Typically, the JavaHL library is in a separate package that is dependent on the main Subversion package. In Debian/Ubuntu the package name is libsvn-java so you can just run this command to install the library:

$ apt-get install libsvn-java # Use sudo in Ubuntu

Next, find the path where the JavaHL library is installed, as you will need to know this path for the following instructions:

$ find / -name # Use sudo in Ubuntu

Although the library is installed, you still have to tell Java (when used for Eclipse) where to find it. The JVM on Linux does not look in a lot of the standard locations to find the libraries. (This could obviously change in the future.) For example, 32-bit Debian/Ubuntu uses a standard location of /usr/lib/jni for libraries to be used from Java. However, the Oracle JVM does not currently look in this location. The easiest way to tell Java where to find the JavaHL library is to specify the following when starting the JVM:





CollabNet Subversion installs into /opt/CollabNet_Subversion. So if you are using that package, you need this:



Eclipse provides its own mechanism for providing this setting. Eclipse comes with a file named eclipse.ini. This file is looked at when the Eclipse launcher starts the JVM and appends settings to the JVM when launching it. Specifically, you should see a line that says "-vmargs". Add a newline after this line and insert the above line to pass the setting the JVM needs. Each argument needs to be on its own line, so be sure to add a new line and then put the entire string above on its own line. Here is an example of this file from Eclipse 3.4:





You can tell if JavaHL has loaded by looking at the Eclipse preferences under Team > SVN. If the library loaded correctly you will see the version of the library, otherwise it will show "Not available". If a version of the library that is too old to use is found, then we do not load the library and it will show as "Not available".

A common problem that Linux users have run into is that they edit the eclipse.ini file to point to the path where the library is loaded but it still does not work. Something to check if this happens to you is whether the settings in the INI file are being used. A lot of users customize the launcher they create to run Eclipse and they include some command line options for starting Eclipse. When you do this, it appears that the Eclipse launcher does not use any of the settings in the INI file. The easiest way to see this is happening is to do Help > About in Eclipse and then choose Configuration Settings. If you look through the settings you should eventually be able to see the command line settings used for the JVM. If you do not see the java.library.path line then it was not used.


Client loads OK on Linux, but locks/crashes Eclipse on first operation

There is currently a bug in the new support for GNOME keyring in Subversion 1.6. It works OK when using the command line, but not when other users of the libraries use it. Until this is fixed, you can workaround the problem by turning off this feature. To do this, open the file ~/.subversion/config and add the following:


### Set password stores used by Subversion. They should be
### delimited by spaces or commas. The order of values determines
### the order in which password stores are used.
### Valid password stores:
###   gnome-keyring        (Unix-like systems)
###   kwallet              (Unix-like systems)
###   keychain             (Mac OS X)
###   windows-cryptoapi    (Windows)
password-stores = 

The empty value for "password-stores" disables the feature. Passwords will be stored in plain text in the auth folder as with all previous version of Subversion.