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