JDK-4452046 : Potential wrong use of Class.forName
  • Type: Bug
  • Status: Resolved
  • Resolution: Fixed
  • Component: xml
  • Sub-Component: org.xml.sax
  • Priority: P3
  • Affected Version: 1.4.1
  • OS: windows_nt
  • CPU: x86
  • Submit Date: 2001-04-28
  • Updated Date: 2012-04-25
  • Resolved Date: 2001-06-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availabitlity Release.

To download the current JDK release, click here.
1.4.1 beta2Resolved
Bug: Potential wrong use of Class.forName

The Class.forName method must be used with care in JRE code. A call
of the type Class.forName(classname) can only be assumes to find classes 
on the bootclasspath, since it does a look up on the callers classloader.

This often leads to problems when what used to be optional packages are
moved into the JRE, since if the code is used as an optional package (i.e.,
loaded using -classpath), then Class.forName(classname) is essential:

    Class.forName(classname, ClassLoader.getSystemClassLoader())

which is NOT the same as Class.forName(classname)

The general rules of thumb for using Class.forName in JRE code are:

 1. Use Class.forName(classname) if you know that only JRE code should be
    found, i.e., no application specific classes should ever be found.
    (This is general, should only apply to the really low-level SPIs)

 2. Use either 

        Class.forName(classname, ClassLoader.getSystemClassLoader()) 

        Class.forName(classname, Thread.current().getContextClassLoader())

   The later should be used if it is reasonable to assume that the lookup
   it related to some computation on the current thread.

Note: For historic reasons, the use of Thread.current().getContextClassLoader()
has some advantages, since the code is more likely to work with both Java Web Start 
and Java Plug-In. Since application classes are typically not available on the
system classloader. [This is what is being addressed in RFE 4372945 - but the
problem will still exist for users with early versions of these products]

It is also clear looking at the JRE code that the Class.forName issue has
been a long standing issue. Various componetns of the JRE are using different
workarounds, e.g., provide the developer with various APIs for setting the
system classloader that the system should use. In these cases using the
Class.forName(classname, Thread.current().getContextClassLoader()) is most
likely the right thing to do, and the developers would not need to worry
about the setting-what-classloader-to-use APIs. This should make it a lot 
easier for our developers to use our APIs, and write code that
works across our different deployment solutions, i.e., Java Web start, Java 
Plug-In, and the java.exe command-line tool.

In some of the Java files below, Class.forName is used with hard-coded class
names. These seems to be often used to detect specific version of a JRE. This
should not be neccesary for code belonging to a 1.4 codebase. That should 
eventually be cleaned up.

Each file is maked with a number:
3.  Uses with Class.forName(xyz, true/false, cl), where cl is an argument to method

5.  Uses a Class.forName, and then a lookup on other classloader

    [That might be a workaround API. Maybe Class.forName(..., ContextClassLoader,SystemClassloader)
     would be better]

4.  A Class.forName look up hardcoded rt.jar class

    [This might not be needed - JRE version checking?]

X.  Just a Class.forName(cl) with possible not rt.jar argument

    [Might be a lingering bug]

5    org/apache/crimson/tree/SimpleElementFactory.java:
X    org/apache/crimson/util/MessageCatalog.java:
4    org/apache/xalan/extensions/ExtensionHandlerGeneral.java:
X    org/apache/xalan/lib/sql/XConnection.java:
X    org/apache/xalan/processor/CompilingStylesheetHandler.java:
X    org/apache/xalan/serialize/SerializerFactory.java:
X    org/apache/xml/utils/ObjectPool.java:
X    org/apache/xml/utils/synthetic/Class.java:
X    org/apache/xml/utils/synthetic/TestDriver.java:
X    org/apache/xpath/compiler/FuncLoader.java:
X    org/xml/sax/helpers/ParserFactory.java:
X    org/xml/sax/helpers/XMLReaderFactory.java:

rene.schmidt@eng 2001-04-27

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic FIXED IN: merlin-beta2 INTEGRATED IN: merlin-beta2

EVALUATION I have already fixed the problems that are in the crimson parser and the SAX factory classes. The remaining problems are in Xalan (XSLT) code so I am assigning this bug to Costin. ed.goei@Eng 2001-04-30 Fixed for xalan too.