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
User: Jesse Glick <email@example.com>
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