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

class loaders should support "local" creation of Package objects

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Other
    • Icon: P4 P4
    • 9
    • 1.4.0
    • core-libs
    • None
    • generic
    • generic

      The rfe, 4302406, describes functionality which is known as "Preferred
      classes." The preferred classes rfe describes functionality which
      will enable a child class loader to prefer its own resources over
      those of a parent. To be consistent with the philosophy described in
      the preferred classes rfe, child class loaders should not only be able
      to override class loader resources but should also be permitted to
      create their own Package objects (i.e. prefer them) even when a parent
      class loader has already defined duplicate Package objects.

      This rfe is related to a merlin bug, 4302406 which discusses the fact
      that though it seems to be a side effect of the current Package
      creation mechanism it is already possible to have duplicate Package
      definitions for a given Java package in a single class loading
      hierarchy. Here is a relevant excerpt:

        - Package sealing does not enforce upward sealing consistently.
          The exact situations in which a sealing violation will be thrown
          depend upon the order in which ancestor and descendant loaders
          actually load resources. If a descendant class loader happens
          to define a sealed package object before an ancestor defines a
          class in a relevant package, then no sealing violation will be
          thrown for any class the descendant defines in a package an
          ancestor may have also defined. In other words, it is currently
          possible for parent and child class loaders to contain duplicate
          and sealed definitions of the same package.

      It is necessary to read the information contained in 4251303 and
      4302406 to understand the need for this rfe.

      In addition, the Class.getPackage() (and related "getPackage") APIs
      exhibit inconsistent behavior. Specifically whether or not a child
      class loader will create its own Package object for a Java package
      foo, depends upon whether its parent has already defined a Package
      object for foo. The child class loader can define classes that the
      parent does not have, but the Package object for those classes will be
      the one contained in the parent - not the child. This precedence of
      parent Package object's can lead to problems (e.g. suppose the child's
      package was of an incompatible version than its parents package... ).

      On the other hand, the class loader delegation hierarchy will allow
      the child to use its own Package object for the classes its defines -
      as long as the child creates it Package object before its parent...

      If a class loader loading preferred classes is allowed to
      create its own duplicates of parent class loader resources, it would
      be consistent to also allow class loaders which understand preferred
      resources to create copies of (potentially sealed) packages that exist
      in a parent class loader. Of course, this ability would circumvent
      some of the intended purposes of package sealing. It may be
      appropriate (to fully support preferred classes) to add an API to
      java.lang.ClassLoader which enables access to Package definitions
      which are "local" to a given class loader.

      -----
      I have also attached a simple test program which demonstrates that
      it is already possible for child and parent class loaders to have
      duplicate copies of Package objects which describe the same Java
      package.


      lairdd@east 2000-01-31

            mchung Mandy Chung (Inactive)
            ldorninsunw Laird Dornin (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: