java javap and groovy bytecode comparison

Question

Here is the code generated showed by javap when I asked him to display my compiled class (I selected method)

int multiply(int, int);
  flags:
  Code:
    stack=2, locals=3, args_size=3
       0: iload_1
       1: iload_2
       2: imul
       3: ireturn
    LineNumberTable:
      line 2: 0
    LocalVariableTable:
      Start  Length  Slot  Name   Signature
             0       4     0  this   LMyClass;
             0       4     1     a   I
             0       4     2     b   I

Here is the code, which displayed by groovyConsole(same method)

public multiply(II)I
   L0
    LINENUMBER 4 L0
    ILOAD 1
    ILOAD 2
    IMUL
    IRETURN
   L1
    LDC 0
    IRETURN
    LOCALVARIABLE this LMyClass; L0 L1 0
    LOCALVARIABLE a I L0 L1 1
    LOCALVARIABLE b I L0 L1 2
    MAXSTACK = 2
    MAXLOCALS = 3

But which bytecode are more raw? As far as I understand, javap added some style to it, so the second example should be more genuine bytecode. Am I right?

score 2 · Accepted Answer · answered Mar 22 '16 at 10:06

2

Neither of these is more raw. There are just two different ways of presenting exactly the same information.

answered Mar 22 '16 at 10:06

yole

92,896
20
260
197

I am curious which of them are more precise in display it the same way as in `class` file and judging by all the assemblers it is the second variant. – lapots Mar 22 '16 at 11:01
The .class file contains binary data. Because of this, neither of these representations shows the data in the same way as it is stored in the class file. – yole Mar 22 '16 at 11:08

score 0 · Answer 2 · answered Mar 22 '16 at 13:20

It looks like both Javap and Groovy do some amount of sugaring, but in different ways, so you can't really say that one is more "Raw" than the other. For example, Groovy displays the raw method descriptor (II)I which Javap sugars, while Javap displays the stack and locals counts and Groovy doesn't.

That being said, neither is particularly "raw". Javap is designed to help with Java debugging, so there a number of things that it tries to hide or rewrite in order to make the output more Java like. It isn't designed to handle unusual or maliciously constructed classfiles at all.

If you want the most "raw" disassembly output, your best choice is the Krakatau disassembler. Krakatau is the only disassembler which can represent every little detail in an arbitrary classfile, including non-java and maliciously constructed classfiles.

java javap and groovy bytecode comparison

2 Answers2