Bug 521660

Description Vladimir Piskarev 2017-08-31 06:11:28 EDT

Hi,

Just to give you some background information, I'm the main developer of Eclipse Handly project, which aims to provide core building blocks and common infrastructure for handle-based language-specific models just like the Java model. (In fact, we're even using a backwards-compatible experimental fork of JDT Core based on Handly, as a proof of concept and a test workbench.) I'm currently working on a facility for model operations and event batching (something like JavaModelOperation). At first, I just wanted to copy the basic design used in JDT, but now have second thoughts about it.

As far as I understand it, the DeltaProcess is a per-thread object which, in effect, segregates model changes (represented as element deltas) by thread, thereby allowing model change events to be sent in the same thread where the change occurred. However, such design is counter to the notification strategy used by the Eclipse Platform resource model. Since the Java model sits on top of the resource model, this raises the question of soundness of the chosen design.

Let me try to explain it, starting from citing bug 306214 comment 4 by John Arthorne:

"In the end there are two possible event strategies here:

 1) Events are sent in the same thread where the change occurred. However, since changes can be interleaved across threads, the listener may receive change events out of order.

 2) Events are sent from any thread, but events are always sent in the order in which the change occurred.

Both strategies have pros and cons, but in the end we chose event order consistency over event thread consistency."

So, while the resource model chose the second strategy, the DeltaProcessor uses the first one. As far as I see, this means that the DeltaProcessor is prone to the following issues:

* Since changes can be interleaved across threads, the listener may receive change events out of order (which is not necessarily bad per itself, being just a design decision, but perhaps should have been communicated to clients more aggressively).

* There is a fundamental disagreement with the event strategy used by the underlying resource model. "You can never reliably predict what thread a given resource change notification will occur in" (to cite John Arthorne again). However, since the DeltaProcessor tries to merge the registered Java model deltas with the element delta translated from the resource delta, it implicitly expects to receive the resource change notification in the same thread that registered the Java model deltas (i.e. the thread in which the Java model operation occurred in). Clearly, this assumption is not correct and, in particular, may lead to lost of fine-grained deltas, which can be demonstrated with a test case (soon to be posted to Gerrit).

I understand that the DeltaProcessor is an old and complicated part of the JDT Core code base that presumably have served well enough, so probably this is a minor issue from the practical point of view and there may be no incentive to change the current design, especially since this might break existing clients. However, I would appreciate any comments. Perhaps some of the old-time committers could shed some light on why the DeltaProcessor had been designed in this particular way. I may well be missing something. Thank you!