I wouldn't just listen to the people that have responded so far saying
that perhaps you should reconsider. The current Java API's that rely on
JNI are bad - as compared to what a native Java version would be. Period.
Let the self-righteous rebuttal start!
There are so many problems with any JNI version of anything that it aught
to be self-evident. But apparently it is not. So let me ask: how well
is that JNI Java port going to work on my handheld using a J2ME JVM? It
won't. Where as I will grant that not too many people will be interested
in accessing a Subversion repository on their cell phone or Palm, there
will be times when it would be handy.
There were similar questions asked when the native JDBC drivers where
written for just about any database you care to mention: 'We already have
CLI versions, why not simply use them and make JNI interfaces?' IBM did
this with DB2, and it was a disaster. They finally have come out with
native drivers.
And what about new platforms? The Subversion code should compile with
little modification on just about any platform, but not really. It takes
time to port and test. With native Java drivers, as long as there is a
JVM, it'll run.
There is nothing wrong with using JNI, where JNI is the only option. Some
of the new stuff in JDK 1.4 with the NIO even makes it better. But a
native Java version will always be faster, easier to debug, and in the
long run, easier to maintain. Look at PostgreSQL. There native JDBC
drivers are some of the best around, and are no longer second class to the
CLI stuff.
So if someone really wants to write a native Java version, we should all
support that, and help out. In the long run it WILL happen, and it WILL
supplant the JNI version. Don't believe me? Point to one JNI interface
that still survives after the introduction of a native interface.
> OK OK ... you convinced me ... I wont do it. *surrenders* It was only an
> idea. *shrug*
>
> In fact the general hostile reactions I have been getting on this list
> to even suggestions doesn't make me want to contribute at all..
>
> Best of luck.
>
> -- Kraythe
>
>
> "Ben Collins-Sussman" <sussman@collab.net> wrote in message
> news:m34qy22mj7.fsf@kepler.ch.collab.net...
>> "Robert Simmons" <derisor@arcor.de> writes:
>>
>> > Yes but where is the design and architecture documentation? ;-) Im
>> not terribly confidently expecting it to exist but it would be
>> convenient. Reading code to figure out architecture is very slow and
>> tedious and most people simply wont bother. If it comes down to
>> having no hints other than the code base, I may not bother. I want
>> to write a library, not learn to write C all over again.
>>
>> Read the entire Subversion book, especially chapter 7. That explains
>> a lot of architecture. There's also a very old, very general design
>> document sitting here, which gives a good overview:
>>
>> http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=259
>>
>> By the way, there is no "one protocol" for Subversion. The access to
>> the repository is an abstract API, so anyone is free to write a custom
>> protocol. At the moment, we have a stateful custom protocol which
>> talks to an 'svnserve' server, and a WebDAV/DeltaV variant protocol
>> that speaks to an Apache server. And and there's a 'no-network'
>> protocol for accessing a repository directly. Which will you
>> reimplement in pure Java? All of them?
>>
--snip--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 22 15:53:32 2003