Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4452032

Potential wrong use of Class.forName

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 1.4.0, 1.4.2
    • Fix Version/s: 7
    • Component/s: client-libs
    • Labels:
    • Subcomponent:
    • Resolved In Build:
      b03
    • CPU:
      x86
    • OS:
      windows_nt, windows_xp
    • Verification:
      Verified

      Description

      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

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              malenkov Sergey Malenkov (Inactive)
              Reporter:
              rschmidtsunw Rene Schmidt (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: