From: Matt A. <one...@fl...> - 2001-05-30 18:06:40
|
For what it's worth, I'll put in my 2 cents; one cent per example in support of Gilbert. I've had to work with professional software that was originally supposed to work with IBM's XML4J package. Later, once Xerces was stable, many people tried to swap out XML4J.jar with Xerces.jar, since they were both supposed to support the same API (SAX and DOM, in the correct namespace as dictated...). However, not only were the factories incompatible (mandating code change), but the classes with the same name were not API compatible, due to subtle variations in the implementation. True, the migration was fairly trivial, and a decent testing framework caught the incompatibilities quickly. What was worse, there were times when we were trying to use, in separate parts of the application, a library that depended on one, and another library that depended on the other. We were forced to implement custom class loaders, which lead to many problems trying to get the middle code to talk to both libraries. Not only that, but it made a dependency between the custom class loader and the installation - now the class loader needed to know the location of both packages in the directory hierarchy (as well as the jar name), as opposed to allowing the user to tell the JVM where they are in the classpath. If XML4J and Xerces had implemented their software in different packages, this problem would never arise. Many said that it was a good thing, because the users of the libraries had very little learning curve between packages, and that it was trivial to migrate between the two. However, placing the libraries in different packages would have made the migration clear to the developer that they were incompatible (very much or very little makes little difference), and would have releaved several days of useless development time working on the class loaders. Nowadays, there's JAXP to bridge the gap between these two libraries and any other new XML library that comes along. That's all I need - another incompatible library to migrate to. Personally, I find that using separate packages for different "major" versions of the software to be very useful. For instance, when I first developed my jplugin framework for the GroboUtils project on Sourceforge, it was a quick and dirty implementation that worked with my then-current application needs. Since then, I've re-analyzed the problem domain, and developed a variation on the framework. Now I can place the new framework in a different package name, allowing me to dictate when I want the application code upgraded, so I have full control over the quality of the product. And, if I develop another library which is dependent upon the second version, my application can easily integrate with that new library without complex class loader code. YMMV -Matt "I'm not an actor, but I play one on TV." |