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.
See issue #118590 and the stack provided there. org.openide.text.DocumentLine$Set fires property changes under Document write lock. If someone needs to run JavaSource.runCompileControlTask as a response to that change, he runs into problems. There is nothing about Document write lock in the Javadoc of Line or Annotatable. Either the firing needs to be revisited or documented.
I don't understand much what you're asking me for. The Line.Set fires the changes synchronously in the same context it receives document modifications in and that is, obviously, a document write lock.
I'm trying to keep a rule not to fire changes under locks, as this can easily lead to deadlocks. Or to problems like issue #118590. If I get an event about modification, it's natural to want to see the updated document. But I can not aquire read lock when it has a write one. For my purpose it would be best to be called under a read lock (write lock should allow to be safely changed to a read lock here). Anyway, this should be at least documented!
Well, your strategy is not reliable in any case where the event contains some data. You'd need to be able to switch from write access to read access atomically, otherwise there might be another modification. between your write and your notification. This is generally only possible using NB's Mutex, not possible using javax.swing.text.Document's locking. Every model I know of fires events directly from the modification, the only major exceptions being NB Projects (which cause a lot of problems to the API clients and is a source of critic) and maybe filesystems, but only in case of explicit atomicAction wrap. The only thing I can do is to explicitely document the fact that the events are fired under the document's write lock, but that would be more than what even javax.swing.text.Document states in its javadoc. And the only reason somebody is ever going to see the current state as some kind of issue is that Java support decided to fail when called in a performance-sensitive context. Anyway, the real problem in case of issue 114608 is the fact that you're requesting parsing in AWT thread, regardless of the locking context it is requested in.
Petr, I really cannot say if this is a criticism or not, but: Java *needs* to check for document write lock, not because of performance implications, but as a deadlock precausion. The tasks inside Java infra run under one lock, and the document lock is the second one. We have tasks that first take java lock and then document lock (and we cannot change this, period). So we cannot allow anyone taking the lock in the opposite order. Sorry. Please note that (despite this check), we got several reports of deadlock caused by this very same problem, on build with disabled assertion. It would be much worse if we did not have this assertion.
Jan, this wasn't criticism, I believe you have a reason. I just stated that the change (adding the assertion) uncovered some hidden "problem". In fact, the change was incompatible, technically speaking. You'd better switch it to real check instead of assertion, though.
Reassigning to new module owner mslama.
Current impl corresponds to firing events in javax.swing.text. They are fired synchronously. On the other hand I do not know if org.openide.text.DocumentLine$Set fires property changes ALWAYS under Document write lock or how to prove it is fired ALWAYS under Document write lock. I even did not find any way how to find out if Dcoument read or write lock is used at given moment (when I have Document instance. So I am reluctant to add this to javadoc.