JDK-4452022 : Potential wrong use of Class.forName
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.sound
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2001-04-27
  • Updated: 2003-08-19
  • Resolved: 2003-08-19
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 Availability Release.

To download the current JDK release, click here.
5.0 tigerFixed
Related Reports
Relates :  
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]

4    com/sun/media/sound/JDK12.java:
4    com/sun/media/sound/JSSecurityManager.java:
4    com/sun/media/sound/NetscapeSecurity.java:
X    com/sun/media/sound/SunCodec.java:
X    com/sun/media/sound/SunFileReader.java:
X    com/sun/media/sound/SunFileWriter.java:
X    com/sun/media/sound/SunFileWriter.java:
X    com/sun/media/sound/SunMidiFileReader.java:
X    com/sun/media/sound/SunMidiFileWriter.java:
4    sun/audio/AudioSecurity.java:
4    javax/sound/midi/MidiSystem.java:
4    javax/sound/sampled/AudioSystem.java:

rene.schmidt@eng 2001-04-27

I'd like to add 

4    sun/applet/AppletAudioClip.java:

from bug 4452049.  The call to Class.forName() was added by the sound team to
attempt to load the Java Sound extensions.  I believe that the they should be
consulted as to the validity of this call.

- ###@###.### 2001-08-24

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b16

EVALUATION ###@###.### 2002-10-30 No time to look into this in the Mantis time frame. Committing to Tiger. The classes listed fall into three categories: - For com/sun/media/sound/Sun*.java, Class.forName() is used in obsolete code, that looks like it can be removed savely. - For javax/sound/*/*System.java, there is backward compatibility code using Class.forName(). The code is used if Java Sound is running on a pre-1.3 VM, which is needed for the Java Sound version shipped with JMF. If we decide to drop the 1.1-compatibility for JMF, this code can be removed/modified, too. Otherwise, there may be a way to modify it in a way that it will not build, but run on pre-1.3 VMs. BTW, one of the new APIs that are under discussion for Java Sound requires generics, thereby creating a dependancy on a 1.5 VM anyway. - Security handling: As I'm not familiar with this, I haven't evaluated it.

PUBLIC COMMENTS Potential wrong use of Class.forName