Crystal Reports 9's Java API depends on a really, really old version of Xerces. We use a particular, recent version of Xerces (more than a major rev. and over a year newer than Crystal's) in our software. It is deeply woven into the architecture because, like everyone in Java server land, we depend on lots of Jakarta libraries (Struts, commons-logging, log4j, Xerces, etc.) either directly or indirectly.
Software we need and want to integrate with is often doing the same thing we are. It's an evolutionarily non-stable strategy if I ever heard of one. We software vendors single-mindedly provide for our own needs, while perpetuating the incompatibilities of all these third party jars, loaded into the ferris wheel of classloaders in our app servers. Good luck to your customers trying to figure out how to reconcile your product's preferences for a particular species or vintage of parser with those of two other products, and maybe the app server's choice too. Thanks, keep doing that please because I like pain.
Who hasn't overrode Weblogic 7's default Xerces and xml-apis versions with much newer versions for some cool tool or library they needed to use? Didja check to see if Weblogic still started OK with that new toy in the system classpath? If it worked -- are you just lucky? Do you need to try it with JBoss/Websphere too?
How flexible are we with all our Jakartian dependencies? Why can't we better accommodate multiple co-existing XML parsers? Does JAXP help us or make things worse? Is this problem so complicated that no one wants to deal with it? Do we follow this dll-like silliness of depending on particular commons-logging, log4j and xerces+xml-apis until Java gets so ponderous to work with that we start fleeing to careers in C# or Ruby or Manadarin? ;-)
Previous Topic
