Issue 21237 changed the BaseDocument.runAtomic() handling. Originally it was like this:
1. Document's writeLock().
2. Process document changes made by Runnable of runAtomic().
a) file-lock acquired => do nothing.
b) file-lock refused => Undo changes made by just performed runAtomic().
Tests require that notifyModify() is called without document's write-lock (although there's likely no client relying on that).
Although 3. and 4b) follow closely there could be another client who could acquire writeLock() between 3. and 4b) and do modifications which is inconsistent.
Therefore I have changed the behavior to a more logical state:
a) file-lock acquired => continue.
b) file-lock refused => continue but throw BadLocationException on any insert/remove attempt.
2. Document's writeLock().
3. Process document changes made by Runnable of runAtomic().
However many clients called runAtomic() although they did not do any document modification. This caused readonly files beeping (modification refused) or Clearcase attempting to checkout file.
These occurrences were rewritten to use Document.render() where possible. However there are clients such as lexer that require to do some operations under exclusive access to document and they were using runAtomic() for that purpose. However now this is no longer desirable.
A new BaseDocument.runExclusive() method should be created with the following contract:
1) Caller thread of runExclusive() would be granted an exclusive access to the document (other threads calling Document.render() or runAtomic() would wait). For AbstractDocument implementations AbstractDocument.writeLock() would be called to gain exclusivity but it's not required generally.
2) Readonly access to the document allowed only. All modification attempts would fail.
3) Nested runExclusive() call is possible.
4) It's not allowed to call runExclusive() from Runnable passed to Document.render().
5) It's allowed to call runExclusive() from Runnable passed to runAtomic().
Created attachment 116593 [details]
Diff of the proposed change
Since o.n.editor.BaseDocument is not a desirable place for API I have implemented the functionality through an API in editor.lib2.
I would like to ask for a fasttrack API review. Thanks.