Without thinking too much about the consequences, it seems to me that Sun should not expose anything beyond the TrAX interface to Xalan, and provide only the standard functionality. This would allow them to change implementations at some point if they wanted to, without breaking anything. Is someone specifically needs Xalan, they should include it themselves, and it should be able to live peacefully alongside Sun's internal implementation (so the classnames would have to change).
Chris Joseph Kesselman wrote: >>Why ugh? >> >> > >Can't speak for Scott, but here's my own concern: In this approach, any >code which wants to take advantage of Xalan APIs (as opposed to the >simplified TrAX view) would have to change all its imports whenever it >wants to move from running against the distributed version to running >against the development version or vice versa. > >If you're shipping Xalan as part of the internals of an application, that >probably isn't a problem. If you're shipping it as a developer's library, >as the JDK is, it could be a serious nuisance. > >There *HAS* to be a better solution. I've come to believe that the whole >assumption that the extension classpath preceeds the user's classpath was >a Bad Design and ought to be fixed. But that's a general JDK issue rather >than a Xalan issue per se. > >______________________________________ >Joe Kesselman / IBM Research > > -- Chris P. McCabe - Senior Software Systems Architect Choice Hotels International - Information Technology [EMAIL PROTECTED] 602-953-4416
