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

Re: Java svn client?

From: Alexander Mueller <alex_at_littleblue.de>
Date: 2001-10-08 08:22:48 CEST

> On Fri, Oct 05, 2001 at 02:35:00PM +0200, Alexander Mueller wrote:
> >...
> > I wanted to avoid a remake of all of the svn implementation and decided to
> > build a java layer that rests upon a native library (using JNI).
> >
> > Thought it would be faster to have such an interface up. Of course this attempt
> > lacks beauty of design (platform independence as major issue). Also it would
> > be pretty hard to have local repository access without DAV, because then
> > you had to implement really all of the details of svn.
> Implementing an SVN library using JNI is the only reasonable way to go.
> There is simply too much code to reimplement, if you want that Java client
> to use the same WC as the cmdline client.
> You could also produce a custom WC model and just use DAV to talk to the SVN
> server. That would eliminate the need for library access. But that is still
> going to be a lot of code.

I definitely do agree to all of this...

> <rant>
> The whole "non-portable" mindset of Java is its biggest detriment. If people
> would get away from that silly notion, then Java might actually make huge
> strides. As it is, because of the refusal to use JNI, it means that Java can
> only talk to Java, that you can't use native libraries, and because of that
> you end up rewriting every single damned program in the universe to fit
> inside the closed Java universe. It is really sad. MSFT's C# knows that
> interop is necessary, and that is going to cause some real pain to the Java
> world -- C# developers are going to see the "Java lockin" -- they'll be able
> to actually *use* existing code and get stuff done with stopping to rewrite
> everything.

In my eyes, the JNI way is a way to get things done. Of course you still
have to take care of every os you want to support with a native class.

> ....

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:44 2006

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.