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
