Support for Javaflow bytecode pattern

[baron1405]

The Apache Javaflow project instruments class files to provide its Continuation capability. One of the bytecode patterns it generates to handle Category 2 parameters is:

NEW
DUP
DUP2_X2
POP2

Unfortunately, when Javassist sees this pattern when moving instructions, it recognizes the NEW DUP and removes it in order to do the move. However, this leaves the DUP2_X2 POP2 abandoned which leads to stack corruption and javassist throwing an exception due to a negative stack height.

Given this involves Category 2 operands, there is not much short of a complete rearchitecting that can be done in Javaflow to accommodate the existing Javassist patterns for NEW. Therefore, I ask the the above bytecode pattern be added to the javassist.expr.NewExpr.canReplace() method. I will submit a patch with the proposed change.

The reason javassist might end up manipulating a Javaflow instrumented class file is through the use of Powermock, which uses javassist to create mocks. Using Powermock to mock Javaflow instrumented classes results in javassist being used against those class.

Pull request #21 has been submitted.

[chibash]

The pull request has been merged.