You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark Phippard <ma...@softlanding.com> on 2006/08/30 15:53:18 UTC
JavaHL problem with 1.4
Sorry to be bringing this up late in the cycle. The JavaHL changes
between 1.3 and 1.4 are fairly minor and I was not anticipating any
problems.
The problem I am running into is that I cannot use the JavaHL JAR file
produced with 1.4, with the Subversion 1.3 libraries. I think that this
is something we should try to support.
We include the Java JAR file with Subclipse, but we rely on the user to
get the native libraries using whatever OS-specific distribution mechanism
is appropriate. During the release candidate phase the only way to get
these is to build from source, and even after GA it will not be easy to
get the 1.4 libraries on a lot of platforms for quite a while.
This creates an impossible chick and egg problem for us with Subclipse. We
want to take advantage of 1.4, but if we start including the JAR file,
someone just trying to start Eclipse when they have the Subversion 1.3
libraries installed will just have their JVM crash.
I have debugged and the problem was caused by r20652. Here is the log
message:
JavaHL: Improve handling of the Subversion client's configuration
directory during native library initialization, and API manipulation.
Depends on r20648's bug fix to svn_config_ensure().
[ in subversion/bindings/java/javahl/ ]
* native/SVNClient.cpp
(setConfigDirectory): When changing the config directory, ensure
that the config area and templates exist in the new location.
* native/SVNClient.h
(setConfigDirectory): Document behavior.
* native/JNIUtil.cpp
(JNIGlobalInit): Remove code block which called svn_config_ensure()
during library initialization, and errored out on failure.
* src/org/tigris/subversion/javahl/SVNClientInterface.java
(setConfigDirectory): Document change in behavior.
* src/org/tigris/subversion/javahl/SVNClient.java
(SVNClient): Call setConfigDirectory() to trigger svn_config_ensure().
Found by: Thiru Kandasamy <th...@collab.net>
Review by: djames
It is basically one line of code:
setConfigDirectory(null);
The null must cause the native 1.3 library to crash.
Other than Subclipse providing a custom version of the JavaHL java
library, does anyone have any ideas for how this could be fixed for 1.4
GA?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
JavaHL compatibility between mismatched native and Java library versions
Posted by Daniel Rall <dl...@collab.net>.
On Mon, 11 Sep 2006, Mark Phippard wrote:
> Daniel Rall <dl...@collab.net> wrote on 09/11/2006 02:24:36 PM:
>
> > Past a certain point (e.g. allow the library to load enough to spit
> > out a "version mismatch" error or something), I don't agree. Trying
> > to support mismatched library versions which were never intended to
> > work with each other is an uphill battle that is going to lead to a
> > matrix of unanticipated problems, and is definitely more trouble than
> > it's worth.
>
> I think our minimum effort going forward should be to insure that any
> version of the JAR from 1.4 onward can load any future version of the
> library and successfully call the getVersion() methods we added in 1.4.0.
>
> Beyond that I'd like to see a best effort attempt at compatability and no
> consideration given to trying to needlessly prevent stuff from running. It
> seems unlikely that an older JAR would not have all of its methods
> implemented by the library and with a newer JAR if your Java code is using
> newer methods you ought to check the library version first.
This sounds reasonable to me.
Re: JavaHL problem with 1.4
Posted by Mark Phippard <ma...@softlanding.com>.
Daniel Rall <dl...@collab.net> wrote on 09/11/2006 02:24:36 PM:
> Past a certain point (e.g. allow the library to load enough to spit
> out a "version mismatch" error or something), I don't agree. Trying
> to support mismatched library versions which were never intended to
> work with each other is an uphill battle that is going to lead to a
> matrix of unanticipated problems, and is definitely more trouble than
> it's worth.
I think our minimum effort going forward should be to insure that any
version of the JAR from 1.4 onward can load any future version of the
library and successfully call the getVersion() methods we added in 1.4.0.
Beyond that I'd like to see a best effort attempt at compatability and no
consideration given to trying to needlessly prevent stuff from running. It
seems unlikely that an older JAR would not have all of its methods
implemented by the library and with a newer JAR if your Java code is using
newer methods you ought to check the library version first.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: JavaHL problem with 1.4
Posted by Daniel Rall <dl...@collab.net>.
On Wed, 30 Aug 2006, David James wrote:
> On 8/30/06, Mark Phippard <ma...@softlanding.com> wrote:
> >Mark Phippard <ma...@softlanding.com> wrote on 08/30/2006 11:53:18 AM:
> >
> >> Sorry to be bringing this up late in the cycle. The JavaHL changes
> >> between 1.3 and 1.4 are fairly minor and I was not anticipating any
> >> problems.
> >>
> >> The problem I am running into is that I cannot use the JavaHL JAR file
> >> produced with 1.4, with the Subversion 1.3 libraries.
When using mismatched libraries (e.g. 1.4.x JAR files with < 1.4.0
native libraries), this problem should occur only when instantiating a
SVNClient (or SVNClientSynchronized) instance. Due to the problem's
occurrence in native code, I don't believe that it can be worked
around without making modifications to the Java source (exactly as
Mark's patch does).
> >> I think that this is something we should try to support.
Past a certain point (e.g. allow the library to load enough to spit
out a "version mismatch" error or something), I don't agree. Trying
to support mismatched library versions which were never intended to
work with each other is an uphill battle that is going to lead to a
matrix of unanticipated problems, and is definitely more trouble than
it's worth.
Rather than continue down this route, in the future I would prefer to
detect mismatched library versions, and output some type of warning
(at least). It would certainly be safer and simpler to do this
straight-away, but alternately, we could hold off until we know of a
show-stopper incompatibility.
> >> We include the Java JAR file with Subclipse, but we rely on the user to
> >> get the native libraries using whatever OS-specific distribution
> >> mechanism
> >> is appropriate. During the release candidate phase the only way to get
> >> these is to build from source, and even after GA it will not be easy to
> >> get the 1.4 libraries on a lot of platforms for quite a while.
> >>
> >> This creates an impossible chick and egg problem for us with Subclipse.
> >We
> >> want to take advantage of 1.4, but if we start including the JAR file,
> >> someone just trying to start Eclipse when they have the Subversion 1.3
> >> libraries installed will just have their JVM crash.
> >>
> >> I have debugged and the problem was caused by r20652. Here is the log
> >> message:
> >>
> >> JavaHL: Improve handling of the Subversion client's configuration
> >> directory during native library initialization, and API manipulation.
> >>
> >> Depends on r20648's bug fix to svn_config_ensure().
> >
> >I have attached a patch that resolves the problem with using the 1.3
> >libraries, and looking at the code that was added in the referenced
> >commit, I believe it maintains the enhancement that was made in that
> >commit for 1.4.
Yup, it does.
> >OK for me to commit and propose for backport? I can easily ship a custom
> >svnjavahl.jar with Subclipse if this does not get in until a 1.4.1
> >release.
>
> Hi Mark,
>
> The patch looks good. +0 to commit and backport to 1.4.x.
I've backported this change to 1.4.x, so it will show up in 1.4.1.
Re: JavaHL problem with 1.4
Posted by David James <dj...@collab.net>.
On 8/30/06, Mark Phippard <ma...@softlanding.com> wrote:
> Mark Phippard <ma...@softlanding.com> wrote on 08/30/2006 11:53:18 AM:
>
> > Sorry to be bringing this up late in the cycle. The JavaHL changes
> > between 1.3 and 1.4 are fairly minor and I was not anticipating any
> > problems.
> >
> > The problem I am running into is that I cannot use the JavaHL JAR file
> > produced with 1.4, with the Subversion 1.3 libraries. I think that this
>
> > is something we should try to support.
> >
> > We include the Java JAR file with Subclipse, but we rely on the user to
> > get the native libraries using whatever OS-specific distribution
> mechanism
> > is appropriate. During the release candidate phase the only way to get
> > these is to build from source, and even after GA it will not be easy to
> > get the 1.4 libraries on a lot of platforms for quite a while.
> >
> > This creates an impossible chick and egg problem for us with Subclipse.
> We
> > want to take advantage of 1.4, but if we start including the JAR file,
> > someone just trying to start Eclipse when they have the Subversion 1.3
> > libraries installed will just have their JVM crash.
> >
> > I have debugged and the problem was caused by r20652. Here is the log
> > message:
> >
> > JavaHL: Improve handling of the Subversion client's configuration
> > directory during native library initialization, and API manipulation.
> >
> > Depends on r20648's bug fix to svn_config_ensure().
>
> I have attached a patch that resolves the problem with using the 1.3
> libraries, and looking at the code that was added in the referenced
> commit, I believe it maintains the enhancement that was made in that
> commit for 1.4.
>
> OK for me to commit and propose for backport? I can easily ship a custom
> svnjavahl.jar with Subclipse if this does not get in until a 1.4.1
> release.
Hi Mark,
The patch looks good. +0 to commit and backport to 1.4.x.
Cheers,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: JavaHL problem with 1.4
Posted by Mark Phippard <ma...@softlanding.com>.
rooneg@gmail.com wrote on 08/30/2006 02:42:19 PM:
> On 8/30/06, Mark Phippard <ma...@softlanding.com> wrote:
>
> > I have attached a patch that resolves the problem with using the 1.3
> > libraries, and looking at the code that was added in the referenced
> > commit, I believe it maintains the enhancement that was made in that
> > commit for 1.4.
> >
> > OK for me to commit and propose for backport? I can easily ship a
custom
> > svnjavahl.jar with Subclipse if this does not get in until a 1.4.1
> > release.
>
> No objection to the change, it seems trivial enough, I'm just
> wondering if it's really something we /have/ to worry about though.
> Why would the new jar file ever be expected to work with the old
> native lib? It's not like you can use a new libsvn_client with an old
> libsvn_wc...
I tried to explain that in my original message. Subclipse includes the
JAR file with our product, and I think this would be fairly common for
anyone using it. But you cannot really provide the native libraries for
platforms other than Windows. So in Subclipse I want to include the 1.4
JAR and the Windows 1.4 native libraries. But a Linux user cannot easily
get the 1.4 libraries unless they want to build from source. Only a very
small percentage of our users is willing to do this.
I realize this is not something we can count on. For example, 1.3 would
crash with 1.2 libraries because 1.3 was changed to call a new initialize
routine in the library. I do think we should strive to make the library
load without crashing. In 1.4, we added new methods that let you get the
version of the library. It would be nice if say in 1.5 I could call this
method, find out the user has 1.4 libraries, and gracefully give an error
that they need to update. The current situation of crashing the JVM is
pretty bad as it gives us zero ability to help the user and be friendly.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: JavaHL problem with 1.4
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 8/30/06, Mark Phippard <ma...@softlanding.com> wrote:
> I have attached a patch that resolves the problem with using the 1.3
> libraries, and looking at the code that was added in the referenced
> commit, I believe it maintains the enhancement that was made in that
> commit for 1.4.
>
> OK for me to commit and propose for backport? I can easily ship a custom
> svnjavahl.jar with Subclipse if this does not get in until a 1.4.1
> release.
No objection to the change, it seems trivial enough, I'm just
wondering if it's really something we /have/ to worry about though.
Why would the new jar file ever be expected to work with the old
native lib? It's not like you can use a new libsvn_client with an old
libsvn_wc...
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: JavaHL problem with 1.4
Posted by Mark Phippard <ma...@softlanding.com>.
Mark Phippard <ma...@softlanding.com> wrote on 08/30/2006 11:53:18 AM:
> Sorry to be bringing this up late in the cycle. The JavaHL changes
> between 1.3 and 1.4 are fairly minor and I was not anticipating any
> problems.
>
> The problem I am running into is that I cannot use the JavaHL JAR file
> produced with 1.4, with the Subversion 1.3 libraries. I think that this
> is something we should try to support.
>
> We include the Java JAR file with Subclipse, but we rely on the user to
> get the native libraries using whatever OS-specific distribution
mechanism
> is appropriate. During the release candidate phase the only way to get
> these is to build from source, and even after GA it will not be easy to
> get the 1.4 libraries on a lot of platforms for quite a while.
>
> This creates an impossible chick and egg problem for us with Subclipse.
We
> want to take advantage of 1.4, but if we start including the JAR file,
> someone just trying to start Eclipse when they have the Subversion 1.3
> libraries installed will just have their JVM crash.
>
> I have debugged and the problem was caused by r20652. Here is the log
> message:
>
> JavaHL: Improve handling of the Subversion client's configuration
> directory during native library initialization, and API manipulation.
>
> Depends on r20648's bug fix to svn_config_ensure().
I have attached a patch that resolves the problem with using the 1.3
libraries, and looking at the code that was added in the referenced
commit, I believe it maintains the enhancement that was made in that
commit for 1.4.
OK for me to commit and propose for backport? I can easily ship a custom
svnjavahl.jar with Subclipse if this does not get in until a 1.4.1
release.
Thanks
Mark