subversion-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marek Parfianowicz (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SVN-4628) Classes with native methods unnecessarily load the svnjavahl-1 native library
Date Fri, 22 Apr 2016 10:09:12 GMT

    [ https://issues.apache.org/jira/browse/SVN-4628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15253680#comment-15253680
] 

Marek Parfianowicz commented on SVN-4628:
-----------------------------------------

{quote}
By the way — your example of using the Version class would have failed with stock JavaHL
before r1525922 because the native methods of the class were not found ... this problem showed
up when I started adding test cases that did not use the SVNClient class. 
{quote}

Well, yes. I just gave the smallest reproducible example. 

The SVNKit provides it's own implementation of the org.apache.subversion.javahl.SVNClient
class: 
 * http://svn.svnkit.com/repos/svnkit/trunk/svnkit-javahl16/src/main/java/org/apache/subversion/javahl/SVNClient.java

so this one "hides" the original SVNClient from Subversion:
 * https://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javahl/src/org/apache/subversion/javahl/SVNClient.java

If you would run the SVNClient from SVNKit, then prior to SVN 1.9.0 it was working fine. 


> Classes with native methods unnecessarily load the svnjavahl-1 native library
> -----------------------------------------------------------------------------
>
>                 Key: SVN-4628
>                 URL: https://issues.apache.org/jira/browse/SVN-4628
>             Project: Subversion
>          Issue Type: Bug
>          Components: bindings_javahl
>    Affects Versions: 1.9.0, 1.9.1, 1.9.2, 1.9.3
>            Reporter: Marek Parfianowicz
>            Assignee: Branko Čibej
>
> In this commit:
> https://github.com/apache/subversion/commit/fd00c8271282c7d7b0283f5e994feba0f00417be#diff-16c43c60e5af2f2a802701c33d649b26
> a static code has been added to load the native library to all classes having native
methods. 
> This is superfluous. Please note that subclasses can provide a non-native implementation
of these native methods. So having a native library is actually not mandatory.
> There's a real problem with SVNKit, which provides a pure Java-based implementation of
SVN protocol, that you cannot use it without having SVN binaries installed. 
> Please have a look at this bug report for SVNKit 1.9.x:
> https://issues.tmatesoft.com/issue/SVNKIT-662
> which actually should be fixed on SVN side...
> ================================================================================
> You have a permission scheme in your JIRA configured incorrectly as I cannot add comments.
So let me answer your questions here:
> bq. (Please provide references to commits in the ASF Subversion repository. The thing
on GitHub is just a read-only mirror and there's no reference to the original revision there.)
> It's this change: http://svn.apache.org/viewvc?view=revision&revision=1525922
> bq. I added the static initialisers because otherwise those classes would not work correctly.
Loading the native method implementations is not superfluous in any sense; JavaHL does not
provide a mandatory initialisation method that could be used for loading the native library.
> Branko, correct me if I am wrong, but my understanding is that JavaHL (https://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/javahl/README)
consists of high level Java API for Subversion and concrete, native, implementation of this
API using core Subversion C API.
> Until subversion 1.9.0 it was possible to use high level API in a way described in https://issues.tmatesoft.com/issue/SVNKIT-662
issue, without the need to have native libraries installed on the system.   Since the cs:1525922
change though, those native libraries are required.
> This causes issues in products like Atlassian FishEye, where SVNKit library is bundled
and used out of the box as the Subversion JavaHL implementation.  Seems like change introduced
in subversion 1.9.0 would require us to bundle OS specific native libraries, just to check
the JavaHL version in runtime.  Seems like an overkill, especially knowing that in default
configuration those binaries wouldn't be used anyway as SVNKit implementation will be used.
> bq. JavaHL does not provide a mandatory initialisation method that could be used for
loading the native library.
> I see your concern here, not sure if loading native libraries in every API class is the
best solution to the problem.  Perhaps a JavaDoc explaining the responsibility of the client
to call NativeResources.loadNativeLibrary(); is sufficient?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message