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())

   or
 
        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]


Bug: Assumes that the parent of system classloader is extension classloader
===========================================================================

The files below assumes that the parent class of the System classLoader is
the extension classloader. This will not neccearily be true due to RFE 4372945,
which allows an application specific classloader to be inserted upon JVM
initialization.

        java/rmi/server/TrustVerifierData.java
        sun/misc/Service.java

It should be evaluated that the use of getSystemClassLoader() is still
working as expected given this potential change in behavior.
     
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())

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())

   or
 
        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 looking 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]

6 java/beans/MetaData.java:
X java/beans/PropertyEditorManager.java:

rene.schmidt@eng 2001-04-27