That's actually covered in the Programmers' Guide. Your question is slightly misformed in that the interesting case involves rules which have not just the same target class and method but also the same location.within that target method. Hence why you will find the answer in the Programmer's Guide under
section The Byteman Rule Language
subsection Rule Events
subsubsection Location Specifiers
At the end of the listing of all available location specifier syntax there are various notes including the following:
"n.b. as mentioned previously, when several rules specify the same location the order of
injection of trigger calls usually follows the order of the rules in their respective scripts. The
exception to this is AFTER locations where the the order of injection is the reverse to the
order of occurrence."
The "as mentioned" appears to be a ghost of some previous incarnation of the manual. However, the gist of this note is correct.
Rules for with AT XXX locations are injected in the order they are installed. So, within a script, two rules specifying the same target class/method/location will execute in script order and across scripts they will execute in script load order.
The execution order is reversed with AFTER locations but that's actually quite consistent when you think about. In both cases the outcome is that rules injected later interpose closer to the actual event itself than rules injected earlier. For example, assume you inject a pair of rules R1 and R2 with locations AT CALL XXX and AFTER CALL XXX. Subsequently, you inject another pair of rules R3 and R4, also with locations AT CALL XXX and AFTER CALL XXX. The order of execution is
- trigger R1
- trigger R3
- call XX
- trigger R4
- trigger R2
The reverse order for AFTER injection allows R3 and R4 to perform and then undo some side effects without rule R2 getting in the way.
The description above may also lead you to see why it works this way. The bytecode transformer applies rules to a target method one at a time from a list of potentially applicable rules which is kept sorted in presentation order. So, AT rules which target the same point preceding a matched bytecode element get inserted one by one directly in front of the bytecode i.e. the final order reflects the presentation order. With an AFTER rule the code is injected directly after the matched bytecode, which means that later injections precede earlier ones.