I have looked at the java bindings too and tried to get them working.
I posted the original question, and since have played with swig.
The design of svn makes use of swig very hard. Svn exposes a mass of interfaces
that reach right through to its underlying libraries (neon etc)
Swig will try to generate wrappers for these too which leads to an unmanageable
mass of interfaces, most of which are superfluous.
This can be turned off by defining mappings for swig, however these mappings did not
appear much simpler than to to a concise JNI wrapper.
To be able to generate or to maintain the java interface *automatically* via swig
is an illusion in my opinion.
Greg Stein wrote:
> On Mon, Dec 16, 2002 at 11:02:04PM +0100, Oliver Geisser wrote:
>>Jesper Steen Møller wrote:
>>>My (perhaps) ambitious goal is to write a Subversion client to build
> Very cool.
>>>How should I contribute?
>>>A. Work on completing/improving/testing the SWIG/Java bindings
>>>B. Adjust/complete the original JNI effort
> I would recommend (A). Over the long-haul, having the bindings automatically
> update w.r.t the libraries' APIs will be much better. Having to hand-code
> each wrapper and maintain that will be a pain and will fall out of sync very
>>Copy the way SWT interacts with native toolkits.
>>The SWT JNI bindings are the smallest possible wrappers around
>>the native C functions. Everything else is done on the
> I'm not entirely sure exactly what SWT does, but that is the recommend
> procedure: wrap the functions exactly as they are -- get them up into the
> other language. In *that* language, create your language-specific and
> language-stylistic abstractions.
> Python and Java and Perl will have *very* different notions of the "right"
> way to expose the SVN functionality. So let the wrappers give you the
> basics, and then do it Right in the other language.
Tel 089 80067094
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Dec 18 09:46:48 2002