I *really* didn't want to continue this touchy thread, but I'd like to
help. If I'm wrong or my opinions are offensive, certainly some kind
soul will enlighten me.
I wonder if I feel the same way other Java enthusiasts do. The language
bindings are uncomfortable for Java. Perl and Python embrace calling
functions at specific memory addresses in native libraries. Java's
Virtual Machine insulates the Java code and the machine from each other.
The fundamental nature of calling native libraries goes against the
ideal of the virtual machine.
The Java developer's kit provides JNI as an accepted (stable?) means of
accessing native code from within the VM. Native calls "un-managed in
.NET" are looked upon as "the last resort". I'm reminded of the hiker
who cut his arm off with a pocket knife to free himself from the
boulder, only after spending days calling for help and trying to think
of another way out. All Java developers I've talked to approach JNI the
same way.
This all leaves Java developers without the same warm fuzzy feeling
everyone else seems to have about programming against the Subversion
code. This is why I'm excited about Alexander Kitaev's work on porting
the Subversion client API to pure Java. I can see why it's more work
than Subversion's developers would deem necessary, but I can only hope
they see how much nicer it will be for Java developers. Eclipse is a
good example of the kind of man-hours, corporate backing, and
mind-numbing work it takes to mesh native code and Java code. They've
made it work, but for most people there are better ways to achieve the
desired result in Java.
HTH,
Kevin
Gili wrote:
> Hi,
>
> This is a continuation of a discussion started here: http://subversion.tigris.org/issues/show_bug.cgi?id=2141
>
> I will quote it for the benefit of everyone (read it from bottom up). My response follows (before I quote the
> original post):
>
> Ok, ouch, that was harsh :) Max, I am sorry for posting in the wrong place but I am new to all of this and
> there is such a thing as newbie mistakes. Sorry again.
>
> On the talking of BDB Java, I got my information from here: http://www.sleepycat.com/products/je.shtml
> If it isn't a 1-to-1 port of the C version please excuse my mistake but then I would advise you to use
> Hibernate and drop BDB altogether.
>
> On the topic of porting Subversion, I did not mean to imply that the amount of work accomplished by the
> subversion project is trivial. I was simply stating that C++ and Java being close relatives in syntax makes it
> relatively easy to move between one language and the next. You really didn't have to get so defensive. There was no
> malicious intent in my post.
>
> On the topic of C being more portable than Java ("I think you will find C compilers are more widely available
> than JVMs"), that might be true but it is far easier to make Subversion work under different platforms when it is
> written in Java than under C. All the major and not so major platforms have a full-fledged JVM and making
> Subversion work across all of them is far more trivial than porting that same code using C. I don't think this
> argument is disputed by anyone.
>
> On the topic of ease of development, I wasn't trying to imply that it is easier to develop under Java as a
> language than under C as a language. Clearly this depends upon the personal experiences and preferences of your
> development team. What I was trying to imply is that in the field of networking, XML and DBs there are awsome
> mature open-source Java libraries out there that would do this for you and ease your development. Stuff like
> Hibernate simply does not exist under C/C++ (as far as I know), there are many other such examples.
>
> On the topic of Hibernate, you wrote: "adapting Subversion to use Hibernate would be a fairly in-depth
> reorganization - i.e. no easier than implement than an SQL backend in C." ... Well, not exactly. Adapting
> Subversion to use Hibernate would be no different than adapting Subversion a new repository format that resides in
> an SQL database (as opposed to BDB which does not use SQL, to my knowledge). The major benefit of using Hibernate
> in Java instead of coding this in C is that once coded *once* against Hibernate, your code will fit on top of *any*
> database. Hibernate abstracts away any DB-specific differences so you can focus on the actual work. This is huge.
> You can stick Subversion on top of MySQL, PostgreSQL, DB2, SQLServer, etc... This opens a lot of doors for
> Subversion.
>
> My point is: there is a lot of value added in porting Subversion to Java. Yes it would require work, but
> there are also advantages there. Please consider them with an open mind and feel free to discuss them with me on
> this mailing list.
>
> Thank you,
> Gili
>
>
> Max Bowsher:
> ----------------------------------
> The posting of this issue is wrong in so many ways.
>
> Firstly, you have thoughroughly ignored the request (in bold red text on a
> yellow background, no less) to raise concerns with the mailing list first.
>
> Secondly, you haven't bothered to check your facts - BDB Java Edition is a
> sort-of workalike containing only some of the C Edition features, not a port.
>
> Thirdly, you indicate that you believe porting Subversion would be "trivial". In
> doing so, intentionally or not, you call the entire amount of work accomplished
> by the subversion project so far "trivial", since the amount of work to port
> code between languages is inevitably proportional to the amount of code!
> I hope it self-explanatory that calling people's work trivial is not a polite
> way to introduce yourself.
>
> Fourthly, you follow this an erroneous assertion about cross-platform support -
> I think you will find C compilers are more widely available than JVMs !
>
> Fifthly, your statements about ease of development are highly subjective - Java
> might be easier for *you* but experienced C programmers would no doubt hold the
> exact opposite view.
>
> Sixthly, from what I can see from reading the Hibernate homepage, adapting
> Subversion to use Hibernate would be a fairly in-depth reorganization - i.e. no
> easier than implement than an SQL backend in C.
>
>
> If you wish to respond to this, please do so on one of the subversion mailing lists.
> ----------------------------------
>
> Gili:
> ----------------------------------
> Consider porting Subversion to Java. Berkeley DB has already been ported to Java
> and I suspect porting Subversion to Java would itself be a trivial matter. The
> major benefit would be better cross-platform support and (generally speaking)
> easier development. Then there is the matter of being able to make use of all
> those great Java core and open-source libraries out there which will make
> networking code easier, XML support (should you need it) easier, etc. Another
> benefit is that you could stack Subversion on top of Hibernate and give it the
> ability to run inside *any* database: MySQL, DB2, SQL server, etc. This would be
> seen as a huge boon for commercial clients.
>
> Let me know what you think.
> ----------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Nov 27 06:29:25 2004