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.
And probably no longer necessary. Originally introduced to LoaderPoolNode to ensure that user changes to the pool order would be persisted - by checking the old orderings, you can see if the new orderings would have changed them. But: 1. Utilities.topologicalSort should be stable when ordering constraints do not contradict the current ordering. And it is fast. So it should be safe to always attempt a resort. 2. There were various bugs in this system: #13880, #28126. The current code also keeps around *deleted* orderings (converse of #28126) and (worse) keeps around ordering info for loaders which no longer exist (sometimes causing NPEs)! So can probably just remove storage of the old IB/IA maps and always do a resort. For bidirectional settings compat, the old maps will be read and discarded; and writing the pool will write fresh empty maps (which should be harmless to older builds).
Note one effect of the proposed change: if you have rearranged the loader pool in such a way as to violate one or more declared ordering constraints from module layers, on next startup the pool will be resorted to satisfy these constraints anyway. Not great, but on the other hand this already happened when modules containing loaders are turned on or off. For the future it is intended to store loader info (if there is such a thing at all) in a .settings file in a folder, using the normal folder ordering system, which is better tested and better able to handle upgrades.
committed Up-To-Date 1.66 core/src/org/netbeans/core/LoaderPoolNode.java
closed