In 1.2beta4 ClassLoader loaded classes can't link against application classes

Suppose you had a 1.1.x application, written as follows, just as we always
said these things must be written:

    class App {
        CL cl;

        void foo() {
            Class task = cl.loadClass("Task", false);
        }
    }

    class CL extends ClassLoader {
        public loadClass(String name, boolean resolve) {
            if (already loaded)
                return that;
            if (findSystemClass()) // <-- (1)
                return that systemClass;
            lets try to find it, say from "my.cl.path" property
        }
    }

    class Task {
        void bar() {
            App p = ...
        }
    }

In 1.1.x, when resolving _Task.bar()_, the virtual machine would ask _CL_
to load _App_. _CL_ would call _findSystemClass_ which looked at:
    i) paths baked into the VM such as rt.jar, classes.zip *and*
    ii) things on CLASSPATH.
This second step (marked (1) in the above example) would find _App_.

In 1.2beta4, with the new extensions mechanism, we have changed the meaning
of _findSystemClass_ to look only at paths baked into the VM such as
rt.jar, and classes.zip. This breaks the example cited above, the JCK
(4138791) and InstallShield (4145623).

The proposed fix is to respecify _ClassLoader.findSystemClass_, so it looks
in the parent class loader. Since the "baseClassLoader" is the default
parent in 1.2, backwards compatibility is restored. Only if the parent of
a _ClassLoader_ is null, a look up in "java.sys.class.path" is performed.

The upside of this proposed fix is that it has been tested to show that it
fixes the above example, the JCK and InstallShield. It appears to be a
reasonable compromise to maintain backwards compatibility for certain kinds
of applications.

The downsides of this proposed fix are:
    * _findSystemClass_ is specified (in both the javadoc and in the JLS)
      to return _Class_ objects "with no assoicated ClassLoader." This
      change negates that claim, because in 1.2 application classes are
      loaded with an instance of a subclass of _URLClassLoader_.
    * It makes the notion of "system class" very very murky. In the past
      a "system class" was defined as "a class on which a _getClassLoader_
      opertaion would yield _null_." With this fix, that would not be true
      anymore. It has been suggested that we deprecate _findSystemClass_
      (because we changed its behavior), and encourage developers to use a
      new method perhaps named _findClassFromParent_. On the other hand,
      with 1.2, writing class loaders is much simpler because of the
      default implementation of _loadClass_, and the need to write only a
      _findClass_ method -- both of which obviates the need to ever call
      _findSystemClass_, so let us leave it alone.

It has been suggested that something similar needs to be done for
_getSystemResource_ as well, and I will be looking at that shortly.

Watch the Comments section of this bug for complete CCC request for this
bug including the javadoc changes.

anand.palaniswamy@Eng 1998-06-10

Looking at the getSystemResource* APIs, it is obvious that the fix

    "respecify _findSystemClass_ so it looks in the parent class loader"

does not work. The getSystemResource* APIs are static methods and
have no notion of parent. A more consistent fix seems to be to specify
that the methods
findSystemClass
getSystemResource
getSystemResources
getSystemResourceAsStream
all look at the base class loader.

anand.palaniswamy@Eng 1998-06-18