Bug 38330 - Add ModuleInfo.getClassLoader()
Add ModuleInfo.getClassLoader()
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Module System
3.x
All All
: P2 (vote)
: 3.x
Assigned To: Jesse Glick
issues@platform
: API, API_REVIEW_FAST
Depends on:
Blocks: 38306
  Show dependency treegraph
 
Reported: 2003-12-26 01:36 UTC by Jesse Glick
Modified: 2008-12-22 21:44 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
Proposed patch (5.32 KB, patch)
2003-12-26 02:13 UTC, Jesse Glick
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2003-12-26 01:36:25 UTC
Needed for issue #38306 - from the Ant module, I
need to load Ant tasks from a named module, using
a class loader derived from the module loader.
Using the SystemClassLoader is not really safe as
it is common for there to be multiple copies of
important libraries in the VM and you would have
no way of knowing which you were getting.

Proposed added API in o.o.m.ModuleInfo:

/**
 * Get a class loader associated with this module
 * that can load classes defined in the module.
 * You can only call this method on an enabled
 * module, and the result may change if the module
 * is disabled and reenabled.
 * The class loader may or may not be shared with
 * any other module, or be the application's
 * startup class loader, etc.
 * @return a module class loader
 * @throws IllegalArgumentException if this module
 *         is disabled
 */
public abstract ClassLoader getClassLoader();

o.n.c.m.Module would rename its current
getClassLoader to getClassLoaderOrNull and
implement this method to throw IAE as appropriate.

Note that the addition of an abstract method to
this class is not an incompatible API change since
it already forbids there to be subclasses except
in core.
Comment 1 Jesse Glick 2003-12-26 01:39:05 UTC
See issue #38306 for branch information.
Comment 2 Jesse Glick 2003-12-26 02:11:56 UTC
Actually it seems o.n.c.m.M.gCLOrNull is unnecessary - no one was
trying to call M.getClassLoader on a disabled module anyway.
Comment 3 Jesse Glick 2003-12-26 02:13:56 UTC
Created attachment 12675 [details]
Proposed patch
Comment 4 Jesse Glick 2003-12-26 02:19:11 UTC
Requesting fast-track review. Simple compatible change. The method has
long existed internally in core; this just exposes it in the Open
APIs. No change needed to arch descs.
Comment 5 Jesse Glick 2003-12-26 03:25:20 UTC
Correction: it seems autoupdate does in fact override ModuleInfo for
its own internal purposes (though it does not expose the instances
externally). So ModuleInfo.getClassLoader should not be abstract but
should instead throw UnsupportedOperationException in the default impl
- this will permit autoupdate to remain unchanged. Will make this
correction in the branch.
Comment 6 Jesse Glick 2004-01-06 16:34:05 UTC
Planned for commit to trunk during the day (US time) on Wednesday.
Comment 7 Jesse Glick 2004-01-07 22:08:08 UTC
committed   * Up-To-Date  1.33        core/manifest.mf
committed   * Up-To-Date  1.50       
core/src/org/netbeans/core/modules/Module.java
committed   * Up-To-Date  1.129       openide/openide-spec-vers.properties
committed   * Up-To-Date  1.182      
openide/api/doc/changes/apichanges.xml
committed   * Up-To-Date  1.11       
openide/src/org/openide/modules/ModuleInfo.java


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo