JavaHL uses JNI to load Subversion shared libraries and it includes a runtime version check to ensure that the loaded library is the right version. A program built with 1.8 would report an error if it loaded 1.7 at runtime. It seems we have introduced a binary incompatibility in 1.9 that causes the JVM to SEGV rather than report an error.
A simple Java program: $ cat xx.java import org.apache.subversion.javahl.*; public class xx { public static void main(String argv[]) { System.out.println("hello"); ISVNRepos repos = new SVNRepos(); } }; Build with 1.8 and run with 1.7: $ javac -g -extdirs /usr/local/subversion-1.8/lib/svn-javahl xx.java $ java -Djava.library.path=/usr/local/subversion-1.7/lib -cp /usr/local/subversion-1.8/lib/svn-javahl/svn-javahl.jar:. xx hello Exception in thread "main" java.lang.LinkageError: Native library version must be at least 1.8.0, but is only 1.7.23-dev (under development) at org.apache.subversion.javahl.NativeResources.init(NativeResources.java:136) at org.apache.subversion.javahl.NativeResources.loadNativeLibrary(NativeResources.java:99) at org.apache.subversion.javahl.SVNRepos.<clinit>(SVNRepos.java:46) at xx.main(xx.java:5) Build with 1.9 and run with 1.8: $ javac -g -extdirs /usr/local/subversion/lib/svn-javahl xx.java $ java -Djava.library.path=/usr/local/subversion-1.8/lib -cp /usr/local/subversion/lib/svn-javahl/svn-javahl.jar:. xx hello Aborted The stack trace shows: Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libapr-1.so.0+0x27b54] apr_threadkey_private_get+0x4 Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j org.apache.subversion.javahl.types.Version.getMajor()I+0 j org.apache.subversion.javahl.types.Version.isAtLeast(III)Z+1 j org.apache.subversion.javahl.NativeResources.init()V+17 j org.apache.subversion.javahl.NativeResources.loadNativeLibrary()V+71 j org.apache.subversion.javahl.types.Version.<clinit>()V+0 -- Philip Martin WANdisco