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.
DataObject's methods delete and rename are synchronized on this. It is dangerous and could cause deadlock, e.g. #17941.
Created attachment 3590 [details] Proposed patch.
I discussed the synchronization model of DataObject and MultiDAtaObject with Yarda. It seems it'd be better to rewrite it a little bit. I'd like to propose the following changes and commit them tomorrow. Attached are both diffs. DataObject changes: ------------------ 1) DataObject - new virtual package private method added - synchObject() - in DataObject returns this 2) DataObject's synchronized methods - the lock changed from this to synchObject's method return value (delete, rename, move). Events' firing are outside of synchronized blocks. 3) listeners() method is synchronized to new static field (listenersMethodLock) MultiDataObject changes: ----------------------- 1) getCookieSet and setCookieSet methods are synchronized on special static field - cookieSetLock (instead of 'this' before) 2) getPrimaryEntry method is not synchronized on special object syncObject anymore. The method is not synchronized, because initialization of 'primary' field was moved to constructor. 3) synchObject is changed in MultiDataObject and returns the returned value from secondary() method. 4) handleCopy, handleMove and handleRename are not synchronized anymore, because these methods are called from synchronized methods of DataObject (rename, delete and move)
Created attachment 3628 [details] DataObject patch
Created attachment 3630 [details] MultiDataObject patch
I am adding Vita and Yarda to CC. If you have time, would you look at the changes, please? Thanks.
Why does synchObject() of DataObject return this? Imagine someone (from another package) extenting it. It will result in synchonizing at a public lock (the this) that is often dangerous.
Ok, I agree. I changed the synchronization of DataObject from this to primaryFileListener (private field).
The patch is applied in release33 branch. I am going to propose to make 3.3.0_WAIVER from this bug.
*** Issue 18145 has been marked as a duplicate of this issue. ***
Marking as verified. This will not go into release330. If some weird stuff occurs in release33 feel free to reopen.
Resolved for 3.4.x or earlier, no new info since then -> closing.