Is there a disassembler + debugger for java (ala OllyDbg / SoftICE for assembler)?

Question

Is there a utility similar to OllyDbg / SoftICE for java? I.e. execute class (from jar / with class path) and, without source code, show the disassembly of the intermediate code with ability to step through / step over / search for references / edit specific intermediate code in memory / apply edit to file...

If not, is it even possible to write something like this (assuming we're willing to live without hotspot for the debug duration)?

Edit: I'm not talking about JAD or JD or Cavaj. These are fine decompilers, but I don't want a decompiler for several reasons, most notable is that their output is incorrect (at best, sometimes just plain wrong). I'm not looking for a magical "compiled bytes to java code" - I want to see the actual bytes that are about to be executed. Also, I'd like the ability to change those bytes (just like in an assembly debugger) and, hopefully, write the changed part back to the class file.

Edit2: I know javap exists - but it does only one way (and without any sort of analysis). Example (code taken from the vmspec documentation): From java code, we use "javac" to compile this:

void setIt(int value) {
    i = value;
}
int getIt() {
    return i;
}

to a java .class file. Using javap -c I can get this output:

    Method void setIt(int)
   0    aload_0
   1    iload_1
   2    putfield #4
   5    return
    Method int getIt()
   0    aload_0
   1    getfield #4
   4    ireturn

This is OK for the disassembly part (not really good without analysis - "field #4 is Example.i"), but I can't find the two other "tools":

1. A debugger that goes over the instructions themselves (with stack, memory dumps, etc), allowing me to examine the actual code and environment.
2. A way to reverse the process - edit the disassembled code and recreate the .class file (with the edited code).

Answer 1

Take a look at JAD Decomplier for decompiling Java code. You can then run an IDE's built-in debugger using produced sources. IDE can be IntelliJ, Eclipse or NetBeans. This approach is not completely automatic, but it should do the job.

Answer 2

I don't think this is really a full answer, but some pointers that may provide something workable:

(1) In terms of viewing and directly working with byte the old BCEL Class Construction Kit can be useful (it's the only GUI editor for byte code I'm aware of).

(2) In terms of debugging and stepping through the bytecode, this Eclipse plugin, which integrates with Eclipse's debugger may meet your needs.

I'm not aware of any utilities that would combine these features and allow you to manipulate bytecode while the code is being executed (at least in the same way you can in OllyDbg, etc.). However, the Java debugger API should be able to support manipulating the code at runtime (though, given the nature of HotSpot and JIT in general, I don't know if it would be possible to rewrite an instruction just before it is invoked -- the currently executing byte code opcode is really an abstraction for how the interpretter chooses to implement the op, unlike native code where the disassembled opcode is, in fact, the instruction about to be sent to the CPU). Alternatively, you could look into the Java Instrumentation API which provides a way to redefine byte code at runtime. And, of course, any of the various open source bytecode manipulation libraries may be able to help or provide inspiration.

And, of course, there is always the option of of circumventing the whole JVM infrastructure and simply attaching a debugger to the JVM process. There's some discussion of this in this question and on this page linked from that question.

The bottom line, however, is, that what you seem to be trying to accomplish, while common-place in the world of native code, is not all that common a practice in the Java world (part of the reason for using Java is abstraction from all the gory details). This, and the relatively trivial nature of byte code decompilation (compared with, say C++) has lead to a situation where this type of requirement is scarce, and so, as a consequence, is this type of tooling.