Allow use of COMPUTE_FRAMES when writing classes whose methods employ JSR/RET
If you set the COMPUTE_FRAMES flag when creating a ClassWriter then the writer
barfs when it encounters a JSR or a RET. This is a PITA and it would be very
useful if this just worked (TM). My bytecode transformer is suffering because
it is injecting code into methods which do not use JSR/RET but the classwriter
is failing to rewrite the class because some of the untransformed methods do
use JSR/RET.
I am not sure quite why this is such a hard thing to do but I guess it must be
to do with handling the code in the target bytecode sequence which the JSR
jumps to rather than handling the JSR instruction itself. At the point where
the JSR occurs the effect is merely to pop a return address off the stack.
If the first JSR into a target bytecode sequence is always a forward reference
then it should be possible to associate the current stack details with the JSR
target at the point where the JSR is encountered and then, when the target
label is visited install the saved stack details as the current stack state.
That should allow the stack layout for the target bytecode to be computed and
frames to be generated as per any other bytecode sequence.
I will be happy to try to write a patch for this and contribute it under a
suitable open source license. Before I do that is there something I should know
about why this was not yet attempted?
regards,
Andrew Dinn
JBoss Principal Software Engineer
Byteman and Transactions Team