On Jan 2, 2018, at 12:35 PM, Charles Oliver Nutter <head...@headius.com> wrote:
>
> Is there a good justification for doing it this way, rather than having
> filterArguments start with the *last* filter nearest the target?
No, it's a bug. The javadoc API spec. does not emphasize the ordering
of the filter invocations, but the pseudocode makes it pretty clear what
order things should come in. Certainly the spec. does not promise the
current behavior. When I wrote the spec. I intended the Java argument
evaluation order to apply, and the filters to be executed left-to-right.
And then, when I wrote the code, I used an accumulative algorithm
with a for-each loop, leading indirectly to reverse evaluation order.
Oops.
There are two ways forward:
1. Declare the spec. ambiguous, and document the current behavior
as the de facto standard.
2. Declare the spec. unambiguous, change the behavior to left-to-right
as a bug fix, and clarify the spec.
I think we can try for #2, on the grounds that multiple filters are a rare
occurrence. The risk is that existing code that uses multiple filters *and*
has side effect ordering constraints between the filters will break.
Question: What does the IBM JVM do? I think they have a very
different implementation, and they are supposed to follow the spec.
— John
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
