Looking at 1.6.23 code [1,2,3,4] the behavior of the propertyGet method was
to return null rather than instance of PropertyData under following
conditions:
* Property is absent
* Value of the property is absent
* Any exceptions occurred while PropertyData object was being constructed
in native code
IMHO it would make sense to change org.tigris portion of JavaHL API to
return null under same conditions.
While this will help for code going forward (if/when fixed), NullPointer
will still need to be caught and handled if running against SVN versions
1.7+ that are already out there. So I am not sure how much this issue can
be addressed in practice, as it would require distros to upgrade their SVN
builds to a version with a fix.
Regards,
Vladimir
[1]
http://svn.apache.org/viewvc/subversion/tags/1.6.23/subversion/bindings/javahl/src/org/tigris/subversion/javahl/SVNClient.java?revision=1485521&view=markup#l1165
[2]
http://svn.apache.org/viewvc/subversion/tags/1.6.23/subversion/bindings/javahl/native/SVNClient.cpp?revision=1485521&view=markup#l904
[3]
http://svn.apache.org/viewvc/subversion/tags/1.6.23/subversion/bindings/javahl/native/CreateJ.cpp?revision=1485521&view=markup#l352
[4]
http://svn.apache.org/viewvc/subversion/tags/1.6.23/subversion/bindings/javahl/native/JNIUtil.cpp?revision=1485521&view=markup#l528
On Mon, Nov 10, 2014 at 11:00 AM, Stuart Rossiter <
stuart.p.rossiter_at_gmail.com> wrote:
> Branko,
>
> On 10 November 2014 10:59, Branko Čibej <brane_at_wandisco.com> wrote:
>
>> On 10.11.2014 11:22, Stuart Rossiter wrote:
>> >
>> > Personally I'd prefer if people used the JavaHL APIs from the
>> > org.apache
>> > namespace. They're far better maintained.
>> >
>> >
>> > So is that a "won't fix since package is deprecated"? Do you want me
>> > to raise a bug report in any case for tracking purposes (or in case
>> > you might flag it as a very low priority fix)?
>>
>> I think this is the second time I saw a complaint about a bug in the
>> org.tigris JavaHL API in 1.7+ ... so I guess the priority was just
>> raised from "no priority" to "low priority". :)
>>
>> I'll see if I can fix it, but don't expect fixes anytime soon, and
>> especially don't expect another 1.7 release with any such fixes
>> backported. It might happen, but I make no promises.
>>
>
> OK great; I appreciate that it's low priority. Do you want me to raise a
> bug for you?
>
>
>>
>>
>>
>> -- Brane
>>
>> P.S.: BTW, I saw your note about "of course should be using SVNKit" over
>> on StackOverflow. Apparently, SVNKit is not very actively maintained; it
>> doesn't even implement all 1.8 features yet (and even basic working copy
>> compatibility with that version took 6+ months to arrive), and AFAIK
>> there aren't likely to be any 1.9-related updates. And it's much slower
>> than JavaHL.
>>
>
> As I said privately, I was actually just trying to preempt "why don't you
> use SVNKit?" answers by saying that I knew this would avoid the need for
> the native library and JAR 'pairing', but I was going the native route for
> licensing reasons. I appreciate that there are other pros to using native
> JavaHL (as you outline); I've edited the StackOverflow question to make
> this clear (and credited your WANDisco suggestion in a comment on the
> accepted answer which suggested the same). Thanks again.
>
> Stuart
>
> --
> ________________________________
> Stuart Rossiter
> stuart.p.rossiter_at_gmail.com
>
> Research Fellow: EPSRC Care Life Cycle Project
> http://www.southampton.ac.uk/clc
>
>
Received on 2014-11-10 17:57:59 CET