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

JDKClassLoader could abort unnecessarily in the future

    XMLWordPrintable

    Details

    • Subcomponent:
    • Resolved In Build:
      merlin
    • CPU:
      generic
    • OS:
      generic

      Description

      Right now, com.sun.corba.se.internal.util.JDKClassLoader is package private, and loadClass is only called from JDKBridge in that package.

      JDKBridge always calls loadClass as

      JDKClassLoader.loadClass(null, className);

      so this bug doesn't actively cause problems.

      If we use JDKClassLoader in the future and pass in a non-null Class, however, we must fix this:

      If aClass is non-null in loadClass (and thus we try to load with aClass's ClassLoader), we

      1) Don't need to search the call stack for the latest user defined loader

      2) MUST cache the failure as a failure with the key {className, aClass.getClassLoader()} rather than using the latest user defined loader

        Attachments

          Activity

            People

            Assignee:
            sbauersunw Stefan Bauer (Inactive)
            Reporter:
            eandersosunw Everett Anderson (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: