2. The order of the constant pool is shuffled, but the choice of LDC over LDC_W is preserved.

A few comments.

1. I assume the current behavior is a design choice: Be forgiving when you read the input; be strict when you write the output. This, however, makes it hard to use Barista for instrumenting bytecode. Most transformations of the bytecode are local and you don't want Barista's encode function to fail because of something you did not do. A solution might be to have a pair of functions, encode and encode_strict. Another way to put it: Without looking at Barista's internals one probably expects (encode x) to succeed when x is the result of decode.

2. There are two solutions, either keep the constant pool in the high-level representation, or recompute LDC/LDC_W while encoding. I prefer the second variant. Could you also drop LDC_W completely from the Instruction (and keep it only in Bytecode)?

The LDC / LDC_W issue is clearly a bug, but I have to give it some thought
before trying to come up with a fix.

The JSR / JSR_W / RET issue might not be a bug. It is pretty clear that they
are part of Java 1.5, but it think they were "removed" in Java 1.6 (most
notably because of bad interactions with stack maps). The fact that they are
present in some JDK 1.6 file is not a definitive answer for me, since I notice
that some JDK classes contain methods with "inaccurate" (albeit valid) values
for max_locals, or max_stack.

Would you have a class file exhibiting the LDC / LDC_W problem?
It would help me to get started.

Thanks for reporting,

Xavier

(0000247)
xclerc (Administrator)2011-12-21 18:12

LDC instructions are now treated as constraints over the
placement of elements inside the constant pool.

Provided that one does not put too many constraints
(i. e. more than the number of indices actually allowed
by LDC), the emitted class files should now be correct.