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.
I believe, the fact that the Sun JDK contains Xalan or Crimson or some
other implementation is an implementation detail. The goal was to
include the *implementation-independent* JAXP API into J2SE which
includes SAX 2 and DOM Level 2 Core support as well as the
javax.xml.{parsers,transform} packages. Since the API is independent
from the implementation, it allows other J2SE implementors such as IBM
to include a different parser if they so desire and still be conformant
to the J2SE specs. The fact that Apache APIs were also included and
exposed was an unfortunate accident that has caused many developers
problems. The plan is to fix this in the future so that developers will
be able to use Apache APIs without interference from the JDK.
BTW, the fix is probably more involved in the Xalan case, so any help
from the Xalan-dev community is welcome assuming you agree with the
plan. Also, I'm no longer directly involved in implementing the package
renaming plan for Sun but those who are should be on this mailing list.
Also, I'd be interested in knowing if anyone still disagrees with this plan.
-Edwin
PS: I probably repeated some of what others have already said above.
