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.
During module reload, all of which happens inside the write mutex, PROP_ENABLED is fired first to false then to true (when the mutex is exited). This is not quite correct since when the mutex is entered and exited, this property has the same value, so technically no change should be fired. Generally ChangeFirer should account for the situation where more than one change within a given write mutex is posted for the same source and property: only one change should be fired; its old value should be taken from the first posted one; its new from the last; and if it is the case that for any pair of adjacent changes posted, the old and new values are both non-null and different, this is an illegal state; and if the old and new values of the single change would thus be non-null and equal, no change at all should be fired. Also Yarda says that ChangeFirer should not need to be a separate thread, you can post a read mutex request and it will run immediately after the write mutex is exited, which would be more predictable.
I am not sure if this is actually a valuable goal.... it seems many more people are relying on module change firing than was a design goal for it (it was intended as a very marginal feature for obscure display purposes, perhaps). Perhaps it should be synchronous, with the write mutex held but only read operations permitted. This would simplify a lot of code and tests too. Basically, there would be a global "firing" flag; mutating methods would first check that it was off, and that the method is inside a write mutex, then do their thing, then turn it on, fire changes, then turn it off. This would make the synchronization very safe and the timing more predictable. What do you think? (Depends on a feature in mutex...) Not for 3.3 but for later.
The requested change in mutex has been implemented, I guess. Otherwise I managed to solve the firing issue, I do not need it anymore.
#13352 is what I was referring to.
Target milestone was changed from '3.4' to TBD.
I have a patch which causes all module system changes to be fired synchronously at the end of the mutator method. Though you are inside a write mutex, you are prevented from making any mutations within the scope of the change callbacks. This is very simple and predictable as threading things go, and should be intuitive for users of the JavaBeans spec which requires something very similar.
ChangeFirer.java 1.5 Module.java 1.32 ModuleManager.java 1.39 Note that ModuleManagerTest still uses a timeout-based PCL when testing whether changes are fired. In fact the timeout could probably now be deleted if desired.
closed