This method is not currently very useful because
it is missing some basic functionality.

1. Ability to set a parent class loader. Currently
it uses the system default loader, i.e.
application classpath. Useless if you want to
allow user-loaded classes access to special things
- e.g. the Ant module in
AntBridge.createUserClassLoader cannot currently
use the standard method, since it needs to pass
the Ant class loader as a parent.

2. Ability to define permissions properly. When
using NbClassLoader, you have full control over
permissions. The current CP.cCL always gives the
loader AllPermissions, which is neither safe in
many cases, nor powerful enough in others. You may
need at least to:

a. Give only standard applet-like permissions, to
protect the VM against buggy or malicious user code.

b. Give the specialized permissions created by
ExecutionEngine.createPermissions(CodeSource,InputOutput)
(*) which permit code loaded internally to run a
user process which will have the correct I/O
redirection and System.exit behavior regardless of
which thread it is running in.

Suggest therefore that you be able to pass in a
PermissionCollection argument, or you may need to
be asked to create a PC based on a given CS,
similar to overriding
SecureClassLoader.getPermissions(CS).


Note that adding these extra arguments might mess
up the cache param somehow - you don't want to get
a cache hit created with a different parent and/or
PC than you requested. Could perhaps continue to
implement the cache, but doubly keyed - first by
weak ref to ClassLoader, then by weak ref to PC or
func:PC->CS or whatever it is.


(*) EE.cP should IMHO be public, not protected -
it is actually used as package private by
NbClassLoader, which is simply a hack, and
prevents non-NbCL impls of the class loader.