incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <>
Subject Re: JavaHL package namespace / migration / compatability
Date Tue, 17 Nov 2009 10:21:24 GMT
On Tue, Nov 17, 2009 at 5:54 PM, Branko ─îibej <> wrote:

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

Yes, but your versioning policy for sure allows incompatible changes
thru some mechanism, typically major digit increment.

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

Wicket must have been one of the major ones in a similar position.
Also, Wicket didn't follow the "domain name" approach that is the
norm, making a change perhaps even less "needed" compared to people
seeing a jar full of "org.tigris" stuff.
Martijn, do you feel like digging into your buried feelings on the subject?

What I remember of Wicket incubation (as a User) was that they had
less stringent versioning constraints, so that it continued to live in
1.x version space, even though incompatibilities were introduced.

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

The "benefit" of the "wrapper breakage" is that they are immediately
deprecated and can be dropped in a future release.

> (And of course that owned-domain rule isn't really broken as long as we
> can make sure that no-one else "steals"

Well, I don't know who/what really is, so I have no comment
other than if you don't pay for the registration there are very little
'assurances', since it may disappear.

> 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

(I have not done C/C++ programming since 1995, and back then libraries
were few and far apart.)

The underlying issue is "naming conflicts", which Sun tried to address
in Java with a simple scheme, but one that only works if people
co-operate. Some people choose to co-operate (I, Apache and others)
and some choose to ignore it. So it boils down to Apache policy more
than anything, in the same way that we *choose* to not make or even
re-distribute LGPL'd code, even though we have the right to do so.

Niclas Hedhman, Software Developer - New Energy for Java

I  live here;
I  work here;
I relax here;

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

View raw message