At 12:12 AM +0200 10/22/03, Robert Simmons wrote:
>Simply no. The javahl uses JNI (Java Native Interface) to speak to
>the DLLs for
>subversion. It is platform locked, not 100% pure java (and thus a bitch to
>integrate into Java IDEs) . I want the lib to be 100% PURE java.
Well, "100% Pure Java" is one road to portability, true. Another is
standardized, portable coding in C. Subversion has chosen the latter
path for the moment, and I suspect you'll find that it builds on or
for nearly any platform with a JVM that interests you. The
Subversion code is certainly not platform-locked; it is "compile-time
portable," as is traditional in C code, rather than "run-time
portable" as with Java. It builds and runs on a wide assortment of
platforms, and the SWIG bindings to the platform-local libraries make
it Java-callable on all those platforms. And Python-callable. And
Perl-callable. And probably a lot of other languages that SWIG
supports, though I doubt anyone's actually tried them with Subversion.
There are also some things you simply can't do from Java, because the
JVM designers couldn't find a portable way to write them ... or,
maybe, just hadn't got around to it. Even as late as 1.4.X, for
example, you don't have full access to manipulating the time stamps
and permissions on files from Java (and these happen to be important
functions to the Subversion working-copy library). So at the least,
your "99 44/100% Pure Java" solution is going to need a smallish JNI
library for these extensions.
One of the advantages of "100% Pure Java" is, of course, that it's so
much easier for the JVM to load; this is especially true of browsers,
which is where the "100% Pure Java" banner was first unfurled. But
if you have even one teeny snipped of JNI, you're committed to all
that annoying LD_LIBRARY_PATH and -Xjni kind of stuff, anyway ...
and, as I say, you *are* committed to at least a few snippets of
non-Java. So, sorry about that! Suck it up, take things as far as
they'll go, and then swing by and check the C code for the rest.
I have no intent to rain on your "99 44/100% Pure Java" parade; if
someone put in the effort, it would be a cool thing to have. I think
it's probably "some several," though, not just one.
To answer your question: at the least, I believe you would have to
reimplement these libraries/directories:
clients/
include/ (you'd need to provide equivalent declarations in your
interfaces or classes)
libsvn_client/
libsvn_delta/
libsvn_diff/
libsvn_ra/
libsvn_ra_dav/ (I'm assuming/recommending you choose the DAV/HTTP
access method)
libsvn_subr/ (actually, I'm only guessing here)
libsvn_wc/
svnadmin/ (unless you only plan to do the mere-user, IDE-accessible stuff)
In addition, you'll need to do, or find, a "100% Pure Java"
implementation of Neon (the "DAV over HTTP" layering library).
You won't need to translate apr or apr-util directly; they're the
portability value you get from the JVM. But I daresay there will be
some miscellaneous utility routines from there that you'll end up
having to reimplement, so be prepared at the least to understand them
when the need arises.
You'll want to to tests/ as well, so you can verify your work.
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835.8090
f: 650.228.2501
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 22 01:52:03 2003