Created attachment 110469 [details]
Diff file

[JG01] Javadoc should be clarified: the first AP which supports the command _and is enabled on it_ will perform it.


[JG02] I think the VolatileArrayField warning (whatever that came from) is probably correct - writing and reading a complex type like an array or structured object without any synchronization could in principle lead to one thread seeing a partially written result. Making the field volatile merely discourages a compiler from optimizing accesses to it, but does not introduce a memory barrier that I know of.

JG01: Fixed

JG02: No. In the JSR 133 (JDK 1.5) volatile read/write was fixed. Before JSR 133 it was allowed for volatile writes to be reordered with nonvolatile reads and writes. But this was fixed by JSR 133. In JSR 133 volatile write ensures visibility of all writes which happened before the volatile write (they cannot be reordered with non volatile writes). The volatile read cannot be reordered with nonvolatile reads. The non volatile write happened before volatile write which happened before volatile read (of the same field) which happened before non volatile read. So there is ordering of the operations. The volatile according to JSK 133 can be seen as half synchronized. The volatile read is RB and volatile write is WB.

Here is how JIT can do reordering according to JSR 133.
1st operation                         2nd operation                         Reordering Allowed
Normal Load/Store                 Normal Load/Store                 Yes
Normal Load/Store                 Volatile Load                          Yes
Normal Load/Store                 Volatile Store                          No
Volatile Load                          Normal Load/Store                 No
Volatile Load                          Volatile Load                          No
Volatile Load                          Volatile Store                          No
Volatile Store                          Normal Load/Store                Yes
Volatile Store                          Volatile Load                         No
Volatile Store                          Volatile Store                         No


Now comes the tricky part (arrays). Suppose:

volatile String[] arr;

which means arr reference is volatile but it does not mean that reference to arr elements is also volatile.
So reading the arr elements:
a = arr[0] is OK as the JVM does volatile read of array reference (RB) and then read of non volatile element reference.

arr[0] = a is NOT OK as it's RB not WB. The JVM read volatile reference of arr (RB) and then does non volatile write of the element.

But in the diff there is no modification of the array after volatile write, so it's OK and warning makes no sense.

I will integrate it tomorrow.

Fixed jet-main c4b75dd33577

Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/c4b75dd33577
User: Tomas Zezula <tzezula@netbeans.org>
Log: #201737:API review of a factory method for creating LookupMerger for ActionProvider