> 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