If one would like to use Xerces in a java app, why should they download it from Apache when it's included in Sun's jvm releases as of 1.4?
I noticed that the "rt.jar" in Sun's jvm for Windows contains an apache folder: jdk1.6.0_11\jre\lib\rt.jar\com\sun\org\apache\,
that contains the following apache folders: bcel, regexp, xalan, xerces, xml, xpath
How does one tell what version of Xerces is being released with a particular Sun jvm release? I looked all over the Sun site - it seems they haven't documented that they are using files from Xerces. They even took the trouble of burying the "org/apache" folder down under the "com/sun" folder -- as if to hide the fact that apache is being used....maybe to take credit for it to make it look like the functionality was developed by Sun? hmmm
Is there a chance that one could successfully compile java code that has references to Xerces classes where the developer's project does not contain Xerces jars, but instead relies on the Sun bundled xerces classes -- and while that code would compile file, there could exist runtime exceptions due to potential classes from Xerces that Sun did not include in its jvm -- while if the project did include the Xerces jars - there would be no runtime errors?
The Xerces package is renamed because in older Java runtimes where it wasn't (JDK 1.4?), it made it very hard to use a newer version. The license that lets Sun do this is included in the THIRDPARTYLICENSEREADME.txt file that's distributed with Java.
The renamed packages are just there to support JAXP, so you shouldn't compile against them if you need to use internal Xerces code. They could go away in the next version of Java, or be renamed to a different location. Either use the standard JAXP APIs, or include the upstream Xerces jar.