Bug 19622

Don't forget about ProxyClassLoader.hacky method:

    // XXX fix later!
    // Currently ICE browser JAR includes a copy of many XML classes,
including
    // two classes in org.w3c.dom.events which are not in Xerces for
some reason.
    // This is a temporary workaround to permit these two classes to
be loaded
    // by the ICE browser even though there is package skew going on.
    private static final boolean hacky(final String pkg) {
        return pkg.equals("org.w3c.dom.events") || // NOI18N
               pkg.equals("org/w3c/dom/events"); // NOI18N
    }

Is not following requirement the same?
"Let module classloader always prefer loading from explicit declared
locations over implicit location such as classpath and bootclasspath."

Also another manifest entry can modify the _always_ meaning but it
just nice to have; always seems to me the right way. 

Maybe. However it is the reverse of the normal classloader rule and
thus potentially confusing. Also it may be incompatible if applied
generally.

Anyway access does need to be blocked to classes for which the module
has no declared dependency.

I would like to explicitly show one case.

Module A depends on module B and xerces2.0.0 library
Module B depends on xerces1.4.4.jar library
Module C dependes on xerces2.0.0 library

A's classloader should use following preference order
  1) load from module jar else
  2) load from xerces2.0.0 library else
  3) delegate to B's classloader else
  4) delegate to system classloader or CNFE

It is probably ineffecient as xerces2.0.0 library may be loaded by
multiple classloaders independently. Introducing classloader per
library/resource could solve it:
  1) load from module jar else
  2) delegate to xerces2.0.0 library classloader else
  3) delegate to B's classloader else
  4) delegate to system classloader or CNFE

Ick, I don't like the A -> B dependency here at all. If B uses some
version of Xerces and A depends on B, by default A should look for
classes in B first. The scenario you describe is a mess IMHO and no
module author should get this behavior by default. In addition, there
are serious compatibility considerations here: current behavior is
that classes loadable from a module are visible for dependent modules
and used preferentially, and we must maintain that default.

Issue #19621 could be helpful if you are using a private extension
from B: B could hide it.

I'm not sure how things could work if Xerces were an autoload library.
If #19621 is interpreted more broadly to mean that a module controls
not only exporting of classes loaded from its JAR and any extension
JARs, but classes it can itself see from its own dependencies, then B
can decide whether to expose its dependency on Xerces autoload to
other modules - probably it would want to hide it as an implementation
detail. In that case, A by dependending on B always forces Xerces
1.4.4 to be loaded; but will only be able to *see* classes from Xerces
1.4.4 if it also declares a direct dependency on that autoload. It
might declare a dependency on Xerces 2.0.0 autoload and use that instead.

MouseEvent and UIEvent (present in icebrowserlitebean.jar) are missing
from our current xerces.jar, as well as xerces.jar version 2.0.0.
These use the org.w3c.dom.views package which does not appear to be in
Xerces.

These events are a part of proposed dom.jar package. Its content can
be compiled from Apache's xml-commons or downloaded with DOM2 specs.
(Still pending legal approval).

Good! That will simplify things.

I am working on this, starting in ProxyClassLoader. May have to make a
branch, TBD.

Created attachment 4709 [details]
Proposed patch

Have patch. Note that there are a number of modules in nb_all which
illegally used classes or resources in org.netbeans.core. In these
cases a dependency must be declared or errors will result.

I plan to commit such dependencies to manifests, but module owners
should check to see if they can remove the dependencies. I am CCing
modules for which a new dependency was required where I do not believe
that the use of the core class(es) is really required or advisable.

There are other modules where I needed to add a dependency to prevent
errors, but where that dependency looked reasonable and intentional,
and it was just forgotten in the manifest.

Done.

In directory ant:
committed   * Up-To-Date  1.42        ant/manifest.mf
In directory apisupport:
committed   * Up-To-Date  1.59        apisupport/manifest.mf
In directory corba:
committed   * Up-To-Date  1.42        corba/manifest.mf
In directory core:
In directory core/src:
In directory core/src/org:
In directory core/src/org/netbeans:
In directory core/src/org/netbeans/core:
In directory core/src/org/netbeans/core/modules:
committed   * Up-To-Date  1.21       
core/src/org/netbeans/core/modules/Module.java
committed   * Up-To-Date  1.4        
core/src/org/netbeans/core/modules/ModuleInstaller.java
committed   * Up-To-Date  1.22       
core/src/org/netbeans/core/modules/ModuleManager.java
committed   * Up-To-Date  1.16       
core/src/org/netbeans/core/modules/ModuleSystem.java
committed   * Up-To-Date  1.27       
core/src/org/netbeans/core/modules/NbInstaller.java
committed   * Up-To-Date  1.10       
core/src/org/netbeans/core/modules/ProxyClassLoader.java
In directory debuggercore:
In directory debuggercore/src:
In directory debuggercore/src/org:
In directory debuggercore/src/org/netbeans:
In directory debuggercore/src/org/netbeans/modules:
In directory debuggercore/src/org/netbeans/modules/debugger:
In directory debuggercore/src/org/netbeans/modules/debugger/support:
In directory debuggercore/src/org/netbeans/modules/debugger/support/nodes:
committed   * Up-To-Date  1.26       
debuggercore/src/org/netbeans/modules/debugger/support/nodes/DebuggerWindow.java
In directory editor:
committed   * Up-To-Date  1.43        editor/manifest.mf
In directory externaleditor:
committed   * Up-To-Date  1.11        externaleditor/manifest.mf
In directory form:
committed   * Up-To-Date  1.47        form/manifest.mf
In directory i18n:
committed   * Up-To-Date  1.45        i18n/manifest.mf
In directory jarpackager:
committed   * Up-To-Date  1.46        jarpackager/manifest.mf
In directory java:
committed   * Up-To-Date  1.52        java/manifest.mf
In directory objectbrowser:
committed   * Up-To-Date  1.42        objectbrowser/manifest.mf
In directory openide:
In directory openide/api:
In directory openide/api/doc:
In directory openide/api/doc/org:
In directory openide/api/doc/org/openide:
In directory openide/api/doc/org/openide/modules:
In directory openide/api/doc/org/openide/modules/doc-files:
committed   * Up-To-Date  1.70       
openide/api/doc/org/openide/modules/doc-files/api.html
In directory web:
In directory web/advanced:
committed   * Up-To-Date  1.47        web/advanced/manifest.mf
In directory web/taglibed:
committed   * Up-To-Date  1.8         web/taglibed/manifest.mf
In directory workspaceswitcher:
committed   * Up-To-Date  1.2         workspaceswitcher/manifest.mf