[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: javahl compatibility question

From: Mark Phippard <markphip_at_gmail.com>
Date: Thu, 17 Jun 2010 08:28:14 -0400

On Thu, Jun 17, 2010 at 8:22 AM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> On Thu, Jun 17, 2010 at 4:16 AM,  <mruhrbach_at_aim.com> wrote:
>> Hello,
>> I am developing a Java program that uses the javahl jar file. What I don't
>> understand however is if it is safe to use one version of javahl (say
>> 1.6.11) with a repository of SVN server 1.5.x. I am a bit afraid of
>> introducing errors into the SVN repository that will not show up
>> immediately.
>> Put in other words: do i have to use
>> - the JAR and .dll / .so that i package with my app
>> - the JAR and .dll / .so that comes with the local installation
>> - the JAR packaged with my app and the .dll / .so of the installation
>> Program and server can be either same or different machines.
> JavaHL, along with the rest of the Subversion libraries, maintains
> backward compatibility in future versions.  If you develop against
> 1.6.11, your application will continue to work against other 1.6.x
> releases and future 1.x releases.  If you know that the local
> installation will contain at least 1.6.0, then you can confidently use
> that JAR and shared library.

That is mostly true. The compatibility you speak of is that the Java
source code level. Due to the way JNI works you must have the same
x.y version of the JavaHL JAR as your native libraries or the native
method calls will not match up. The .z should not matter though.

The original question references the server and repository. Those can
be any 1.x version as Subversion compatibility rules dictate that
any1.x client can talk to any 1.x server. The main thing that matters
is that your JAR matches up with the native libraries being used on
the client where the JAR is used.

Mark Phippard
Received on 2010-06-17 14:28:51 CEST

This is an archived mail posted to the Subversion Dev mailing list.