Question

I’ve inheirited support for a legacy web app which is directly using the **.internal.** apache xerces classes within the rt.jar. I think the history is that this code (back in java1.4) used to explicitly use xerces and at some point when moving to java5 use of the xerces jar was dropped and those classes were referenced out of rt.jar as the internal equivalents.

I’m trying to understand what the impact of running this project on various web containers will be (e.g Websphere versus Tomcat etc).

• Is rt.jar supplied by SUN or the JVM/JRE vendor?
• Do alternate vendors continue to use xerces internally or are there other XML implementations?

At some point (resource permitting) this code will need to be changed to use the standard java APIs, I was want to get a handle on how big a problem this might be.

Thanks, Rob

Answer 1

Nowhere in the JVM Specification or the Java Language specification is the rt.jar even mentioned and all the *.internal.* packages are explicitly marked as not being part of the API.

Therefore it’s safe to assume that using any of those binds you pretty directly to the JVM vendor and implementation version. Not only can different vendors use different XML parsers, but even within one vendor, you can easily run into an issue when they change the XML parser, the version of the XML parser or the package in which the XML parser is shipped.

All of those are perfectly legal changes, since those packages are not API.

So unless you’re fine with being bound to a small set of known-good JVMs you should definitely switch to using the standard APIs or at least use Xerces as an external dependencies and thus from the normal org.apache.xerces.* packages.