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

Re: Java binding - SWIG or not?

From: Alexander Mueller <Alexander.Mueller_at_littleblue.de>
Date: 2002-12-17 14:53:54 CET

Jesper Steen Møller wrote:
> My (perhaps) ambitious goal is to write a Subversion client to build
> into Eclipse.
>
> I'll be needing the functionality of the svn_client.h stuff and it's
> direct dependents, and I'd much rather use some JNI constructs than
> having to rely on the SVN command line client, so I can stay away from
> all the command line handling nonsense.
>
> Since the stuff in subversion/bindings/java is incomplete *and*
> outmoded, and I saw some fairly recent postings about the SWIG wrappers,
> without any conclusion about the completeness, my question is really:
>
> How should I contribute?
> A. Work on completing/improving/testing the SWIG/Java bindings
> B. Adjust/complete the original JNI effort
>
> I'm finding the current state of the SWIG/Java binding somewhat, er,
> un-Javaish, if I may, but I might just have understood little of it,
> being new to SWIG.
>
> -Jesper
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
In my opinion it is better to go the SWIG way. During the
implementation of the current JNI bindings I learned the hard way that
you have to repeat yourself during coding much too often. I think it
would be good to use the SWIG/Java wrapper as a first step in the Java
world. You could build a nicer class set (namings, structure) around this.

Alex

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 17 21:30:38 2002

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.