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

RE: Port Subversion to Java

From: Fewster, Robert <robert.fewster_at_malibugroup.com>
Date: 2004-11-26 21:46:13 CET

> 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.

Newbie'ness aside, to suggest to a development team that they
should move their development efforts to different platform is
just plain rude IMHO.
 
> 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.

Subversion is written in C, not C++... that makes them significantly
different in syntax. In addition, the semantic differences
between a interpreted garbage collected language and compiled
language would involve re-designing many parts of the application.
 
> 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.

C compiler support is more robust and stable on more platforms
than JVM's are at this point in time. The promise of Java
portability remains just that - a promise.

It may well be fullfilled, but it hasn't been just yet.

> 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.

There are considerably more libaries in C and C++ than there are in
Java, and they are likely more mature because they have been the
building blocks for *nix variants for 10-20 years before Java was
even a gleam in James Gosling's eye.

(for example, the APR which Subversion uses to such good effect)
 
> 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).

SQL compliance is not an advantage for the operations that version
control systems typically need to do on the data they manage.

> 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.

Could also argue that writing something -like- Hibernate in C
that does the same thing would also open the same doors. It
just wouldn't involve rewriting the rest of the application.
 
> 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.

I feel your argument supporting rewriting Subversion in Java is
weak. I don't concur that the advantages outweigh the effort
involved, nor are there any inherent benefits from the Java
community and infrastructure that aren't also present in the
C/C++ community.

Regards,

RKF

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Nov 27 05:15:03 2004

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