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

java.lang.ClassLoader.loadClassInternal(String) is too restrictive

    Details

    • Subcomponent:
    • Resolved In Build:
      b47
    • CPU:
      generic, x86, sparc
    • OS:
      generic, solaris_8, windows_2000
    • Verification:
      Verified

      Backports

        Description

        Name: nt126004 Date: 04/17/2002


        FULL PRODUCT VERSION :
        java version "1.3.1_01"
        Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_01)
        Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode)

        FULL OPERATING SYSTEM VERSION :

        Microsoft Windows 2000 [Version 5.00.2195]

        A DESCRIPTION OF THE PROBLEM :
        Under Bug Id 4406709, someone has recently
        (unsuccessfully) filed a bug wrt the "private synchronized"
        modifiers of the method

        java.lang.ClassLoader.loadClassInternal(String name)
        throws ClassNotFoundException;

        leading to deadlocks in his derived special-purpose
        classloaders.

        The bug has been closed because of not being a violation
        against the spec. That is perfectly true.
         
        However, I want to reissue that topic here, but this time
        under the "Ease of Use" or rather "Huge Amount of Fantastic
        Possibilities" category.

        In JBoss3.0 (http://www.jboss.org), we have - or rather
        Marc Fleury has - quite successfully experimented with a
        non-tree-based, runtime-dependency-checking classloader
        delegation model that has a lot of nice modularity and hot-
        deploy features. These features cannot be reached by
        the "traditional" tree model.
         
        In that model, as opposed to the tree model, it is
        legal to dispatch a loadClass(String name) call to
        another classloader that is NOT a parent of
        the initiating classloader that is, e.g., trying to
        satisfy a link.

        Depending on the topology of the classloader graph,
        deadlocks as caused by non-interceptible
        loadClassInternal calls are hence likely to occur if not
        countermeasures are taken (e.g., restricted threading while
        accessing the classloaders). Since there is no safe way to do
        that, spurious deadlocks still happen.
         
        Delegating to separate objects that are not affected by
        the classloaders locks as proposed by one of the SUN
        engineers in response to the previously filed bug is not
        possible, because we have to re-delegate to
        other -potentially locked- classloaders in the end.

        You see that I?m deeply disappointed with the current
        resolution of this issue. I hope you understand the huge
        possibilities that appear when relaxing the current
        solution. Having loadClass() synchronized or
        loadClassInternal() protected should IMHO suffice to meet
        the specification requirements, shouldn?t it?

        I know that I am maybe not in the situation to sufficiently
        motivate or explain the issue, but I know that it is a
        highly important piece of the VM!

        I hope that other (more involved) people can add comments
        with code to back-up this request more appropriately than I
        am able to do.
        (Review ID: 145293)
        ======================================================================

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  acorn Karen Kinnear (Inactive)
                  Reporter:
                  nthompsosunw Nathanael Thompson (Inactive)
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  5 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:
                    Imported:
                    Indexed: