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.
In the interests of failing early and predictably with a helpful diagnostic message, rather than behaving erratically, the NB "system" class loader (the default thread context class loader), which is capable of loading classes (and resources) from all modules, should simply refuse to load a class (or resource) when there would be more than one choice of module (parent class loader) to load it from. This would save people from cryptic class linkage errors etc. in cases where a library is present (possibly in different versions) in multiple modules, and some code is calling Thread.gCCL to load something from this library. Background information is given in wiki (see URL), which would be a good detail message for the exception. (ClassNotFoundException?)
Probably too risky to change this behavior in 6.0.
To be evaluated for 6.5.
Implemented in #a0c528f7976a.
Integrated into 'main-golden', available in NB_Trunk_Production #206 build Changeset: http://hg.netbeans.org/main/rev/a0c528f7976a User: Jesse Glick <jglick@netbeans.org> Log: #118020: forbid ambiguous delegation to parent class loaders.
You implemented it for all class loaders, not only for the system one, right? So maybe you'd better guard the additional attempts with an assert to not slow down class loading, though the startup cache might downplay the impact (for a slight size growth). Keep in mind that parts of openide are loaded this way...
There are only a few packages which in fact overlap. Anyway the error is believed not to be thrown in the standard NB IDE so the main purpose is to assist diagnosis for people using third-party modules, which are most likely to be running atop an IDE release in which assertions are disabled.
*** Issue 22508 has been marked as a duplicate of this issue. ***
This issue had *4 votes* before move to platform component