JDK-8201371 : filterArguments runs multiple filters in the wrong order
  • Type: CSR
  • Component: core-libs
  • Sub-Component: java.lang.invoke
  • Priority: P3
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 11
  • Submitted: 2018-04-10
  • Updated: 2018-04-13
  • Resolved: 2018-04-10
Related Reports
CSR :  
Relates :  
Description
Summary
-------

Fix the implementation of `MethodHandles.filterArguments` to conform to the specification (the pseudocode) and clarify the specification as the pseudocode behaviour could easily be missed. 

Problem
-------

`MethodHandles.filterArguments` pseudocode specifies that the filter method handles are invoked in argument order from left to right.  However, the implementation invoked the filter method handles from right to left. This behaviour is observable if the filter arguments retain some global state that affects the results, likely an edge case. However that edge case is exposed for string concatenation using invokedynamic where the `toString` implementation has side-effects that affect the `String` result (see JDK-8200118).

Solution
--------

Fix the implementation to invoke filter method handles in argument order from left to right. Clarify the specification.

Specification
-------------

Update to JavaDoc of `java/lang/invoke/MethodHandles.java`:

          * specified in the elements of the {@code filters} array.
          * The first element of the filter array corresponds to the {@code pos}
          * argument of the target, and so on in sequence.
    +     * The filter functions are invoked in left to right order.
          * <p>
          * Null arguments in the array are treated as identity functions,
          * and the corresponding arguments left unchanged.

Comments
Approving the retroactive CSR. As a general note, a case like this where the specification and implementation disagree can require a CSR due to the potential behavioral compatibility impact. The default resolution of such cases, although not the one being followed here, is to change the specification to match the existing behavior. At your discretion, consider creating a release note for this change.
12-04-2018

Hi Joe, in this particular case, we had no choice, IBM has it's own implementation of java.lang.invoke that works as the specification says. Changing the specification according to the OpenJDK implementation would be rude.
10-04-2018