javap shows an incorrect type for operands if the 'wide' prefix is used

FULL PRODUCT VERSION :
java version "1.7.0_03"
Java(TM) SE Runtime Environment (build 1.7.0_03-b04)
Java HotSpot(TM) 64-Bit Server VM (build 22.1-b02, mixed mode)


ADDITIONAL OS VERSION INFORMATION :
Linux ukko093 3.0.0-17-server #30~lucid1-Ubuntu SMP Fri Mar 9 15:44:12 UTC 2012 x86_64 GNU/Linux


A DESCRIPTION OF THE PROBLEM :
If a bytecode instruction is prefixed with the wide (opcode 196) prefix, javap will disassemble the operands incorrectly.

If the instruction modified is istore, dload, etc., the operands will be incorrectly decoded as constant pool references instead of local variable indices.

If the instruction modified is iinc, the first operand gets incorrectly decoded as a constant pool reference instead of a local variable index. The second operand is decoded completely incorrectly (it seems that only the high byte is shown).

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Compile the attached samples (WideIinc.java or WideLocals.java)
2. Run javap -c on the compiled classes.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
In the WideLocals sample, operands to istore_w and iload_w should not be decoded as constant pool references.
  
    1526: istore_w 256
    1530: iload_w 256
    1534: iconst_1
    1535: iadd
    1536: istore_w 257

In the WideIinc sample, the first operand should not be decoded as a constant pool index, and the second operand should be decoded correctly.

       2: iinc 1, 1
       5: iinc 1, 51
       8: iinc 1, 101
      11: iinc_w 1, 151
      17: iinc_w 1, 201
      23: iinc_w 1, 251


ACTUAL -
In the WideLocals sample, the local variable index in istore_w and iload_w is treated as a completely unrelated constant pool reference (I had compiled with -g, so the entries happen to point to the local variable names).

    1522: iload 255
    1524: iconst_1
    1525: iadd
    1526: istore_w #256 // Utf8 x241
    1530: iload_w #256 // Utf8 x241
    1534: iconst_1
    1535: iadd
    1536: istore_w #257 // Utf8 x242
    1540: iload_w #257 // Utf8 x242
    1544: iconst_1
    1545: iadd
    1546: istore_w #258 // Utf8 x243

In the WideIinc sample, the first operand in iinc_w is incorrectly decoded as a constant pool reference, and the second operand is completely incorrect.

       2: iinc 1, 1
       5: iinc 1, 51
       8: iinc 1, 101
      11: iinc_w #1, 0 // Method java/lang/Object."<init>":()V
      17: iinc_w #1, 0 // Method java/lang/Object."<init>":()V
      23: iinc_w #1, 0 // Method java/lang/Object."<init>":()V
      29: iinc_w #1, 1 // Method java/lang/Object."<init>":()V
      35: iinc_w #1, 1 // Method java/lang/Object."<init>":()V
      41: iinc_w #1, 1 // Method java/lang/Object."<init>":()V

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
http://www.cs.helsinki.fi/u/tmtynkky/WideLocals.java is a generated sample that uses lots of local variables like this:
...
        int x5 = x4 + 1;
        int x6 = x5 + 1;
        int x7 = x6 + 1;
...

http://www.cs.helsinki.fi/u/tmtynkky/WideIinc.java is a generated sample that
perform lots of integer increments like this:
        int i = 0;
...
        i += 201;
        i += 251;
        i += 301;
        i += 351;
        i += 401;
        i += 451;
...
---------- END SOURCE ----------