This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 37437 - Missing abilities in ClassPath.createClassLoader: parent & permissions
Summary: Missing abilities in ClassPath.createClassLoader: parent & permissions
Status: NEW
Alias: None
Product: java
Classification: Unclassified
Component: Classpath (show other bugs)
Version: 3.x
Hardware: All All
: P3 blocker (vote)
Assignee: Tomas Zezula
Keywords: API
Depends on:
Blocks: 41448
  Show dependency tree
Reported: 2003-11-23 15:55 UTC by Jesse Glick
Modified: 2009-11-12 05:50 UTC (History)
0 users

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2003-11-23 15:55:31 UTC
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
(*) 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

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.
Comment 1 Jesse Glick 2004-04-02 21:35:53 UTC
Note that NbClassLoader has a new constructor that permits these options.
Comment 2 ehucka 2005-03-16 08:46:04 UTC
old tagret milestone, please re-evaluate