Re: A packaging scheme...
On Wed, Sep 29, 1999 at 01:28:01PM -0400, Seth M. Landsman wrote:
> Yes and no. Sun has defined the API, which goes under java.* and
> the extended api, which goes under javax.*. However, they do define
> com.sun classes and net.jini classes, which do follow their definition.
> I've found it very useful, very often, to be able to have several
> packages in my classpath, all of which define the same classes, but have
> different qualified names.
Ok, point for you.
> Hmm, so there is one true regex package? Who writes it? i.e.,
> lib.regex.* is going to be real difficult, since there are around five
> regex classes out there. How does this deal with that issue?
> The problem is that the classpath mechanism, for good or bad,
> really does require well qualified package names that won't clash. I do
> not want to change my classpath depending on whose regex library I use.
> I'd much rather talk about that library specifically.
But why do these types of things happen with C libraries? People like the
idea that they can go to a single library and that if they use it their
code will just "work" on a variety of other systems. The Sun system
introduces some serious versioning and configuration management issues.
The combinatory incompatibilities that you can run into while trying to
bring a group of disparate classes together can get mind boggling. It
comes down to knowing that you use versions 1.x of this and 2.3.x of that
and 3.1.x of the other, rather than simply 2.0 of some common library.
My main arguement is that this seems to happen with C libraries in the
Open Source realm and I don't see why it shouldn't happen to Java libraries.
E
--
_______________________________________________________________________
Ean Schuessler Director of New Products and Technologies
Novare International Inc. The Unstoppable Fist of Digital Action
--- Some or all of the above signature may be a joke
Reply to: