incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <>
Subject Re: JavaHL package namespace / migration / compatability
Date Tue, 17 Nov 2009 09:54:29 GMT
Niclas Hedhman wrote:
> On Tue, Nov 17, 2009 at 5:11 PM, Branko ─îibej <> wrote:
>> I don't quite understand the point of this. Here we are with a Java
>> wrapper library for the Subversion APIs. The versioning rules that apply
>> to it are the same as for the rest of Subversion -- in other words, we
>> *must* keep the same package names in the JavaHL public API.
> "Must" is a strong word, and a compatible path forward is suggested.

"Must" is just a result of what our API versioning policy promises to
our users. Any number of compatibility layers won't change that.

>> Is there a
>> specific reason for doing a bunch of extra work that does not add any
>> value to JavaHL but only adds a layer of indirection for /all/ users of
>> the library?
> Java coding standard(s) makes very strong assertions that package
> names should be 'owned' domain names, to ensure avoidance of name
> collisions. Apache has maintained such for practically all projects,
> incl all incoming projects, and I am somewhat confident that some of
> these projects have more dependent developers than Subversion.

I'm sure they do. But could anyone who was involved with any of these
adopted projects share their experience with changing the package names?
How did that affect their users? Did they write compatibility wrappers
with the old package names, too? Did they have an equivalent version
compatibility policy?

I'm not steadfastly against completely changing the JavaHL API and
writing compatibility layers, but I really would like to understand the
reasons; other than Java coding standards which you can't reasonably
expect to apply, since the compatibility wrapper breaks them in the very
same way that the current API does.

(And of course that owned-domain rule isn't really broken as long as we
can make sure that no-one else "steals"
> The indirection overhead would be "optional". Do a
> "s/org.tigris/org.apache/g" replace and you are good to go without the
> overhead.

I don't know what you're used to, but I'd find it very strange indeed if
I had to make massive changes to my code just because some company
bought my library vendor. Not /quite/ the same situation, but for
example, we didn't have to change one line of code in Subversion to
support new versions of BDB after Oracle bought Sleepycat

-- Brane

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message