Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Does the contents of rt.jar change across different JVM vendors?

Tags:

java

xml

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

like image 811
RobLucas Avatar asked Jul 27 '09 11:07

RobLucas


People also ask

What does RT jar contains?

rt. jar contains all of the compiled class files for the base Java Runtime environment, as well as the bootstrap classes, which are the run time classes that comprise the Java platform core API.

Where is Rt jar stored?

3) In windows, rt. jar will always reside under $JAVA_HOME/jre/lib, where $JAVA_HOME refers to the JDK installation directory. Even if you don't install JDK and just install JRE, you will see it in the exactly the same location, you won't find rt. jar inside $JAVA_HOME/lib directory.


1 Answers

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.

like image 197
Joachim Sauer Avatar answered Oct 21 '22 13:10

Joachim Sauer