I don't know if I think JB should spend their time implementing that feature. It's a more natural feature for CodeGuide because they use their own proprietary compiler, so they can compile a method on the fly to see what its locals would look like. However, it seems that this would be a huge project in IDEA, because it has no such compiler.
I think you exaggerate the problem a lot. IMHO all that is needed is a mapping of local variable index (as stored in the byte code) to and from variable name. That can very easily be extracted from the parse tree which is already available in Idea (PSI structure). But maybe I am missing something?
I think you exaggerate the problem a lot. IMHO all that is needed is a mapping of local variable index (as stored in the byte code) to and from variable name. That can very easily be extracted from the parse tree which is already available in Idea (PSI structure). But maybe I am missing something?
I haven't worked with bytecode directly, but in the intermediate format of the Soot compiler, lots of locals are created for things you don't ever see in code (like intermediate results of nested expressions, references to this, references to fields generated when you use anonymous and local classes).
It would probably not require full compilation of the method to determine which locals correspond to which variables in the code, but I think it would be close.
This is kind of interesting. For parameters the simple approach definitly would work. See Java Virtual Machine Specification:
3.6.1 Local Variables The Java virtual machine uses local variables to pass parameters on method invocation. On class method invocation any parameters are passed in consecutive local variables starting from local variable 0. On instance method invocation, local variable 0 is always used to pass a reference to the object on which the instance method is being invoked (this in the Java programming language). Any parameters are subsequently passed in consecutive local variables starting from local variable 1.
I think intermediate results are only on the stack, not in the local variable table, but that's really just an assumption. One would have to dig deeper.
Still, even if omnicode has a custom compiler, it does not compile the JDK itself. It runs on any JDK you supply. So it must be possible top infer local variables without re-compiling the byte code.
Still, even if omnicode has a custom compiler, it does not compile the JDK itself. It runs on any JDK you supply. So it must be possible top infer local variables without re-compiling the byte code.
I guess that CodeGuide semi-compiles the method you're currently stepping in, on the fly, then uses the locals it generated to guess what locals are in the actual JDK bytecode.
Should it not be possible to solve this problem by recompiling JDK classes (with debug info included) and including the recompiled jar into the project as a library?
I tried that with Swing classes, but to no avail. I made sure to place my library first (before JDK libraries). Am I missing something?
Should it not be possible to solve this problem by recompiling JDK classes (with debug info included) and including the recompiled jar into the project as a library?
I tried that with Swing classes, but to no avail. I made sure to place my library first (before JDK libraries). Am I missing something?
Yes. Let's say you have compiled Swing into swing-debug.jar. What you need it to tell the VM that your jar is the main runtime one, not the one in the Java installation direcotry. To do so, add the following virtual machine parameter to the Run configuration:
-Xbootclasspath:/path/to/swing-debug.jar
That way the VM will first load the classes from you swing-debug.jar and that way will skip the original swing classes.
It worked for me, I hope it will work for you also.
Andrei wrote:
I think it's because the JDK classes were not compiled with debug info,
probably for performance or classfile size.
Keith, that's true, but it's also kind of a lame excuse.
While other debuggers can extract the needed information from source code, Idea is just too dumb to do so:
http://www.jetbrains.net/jira/browse/IDEABKL-1490
Stephen Kelvin wrote:
I don't know if I think JB should spend their time implementing that
feature. It's a more natural feature for CodeGuide because they use
their own proprietary compiler, so they can compile a method on the fly
to see what its locals would look like. However, it seems that this
would be a huge project in IDEA, because it has no such compiler.
I think you exaggerate the problem a lot.
IMHO all that is needed is a mapping of local variable index (as stored in the byte code) to and from variable name.
That can very easily be extracted from the parse tree which is already available in Idea (PSI structure).
But maybe I am missing something?
Stephen Kelvin wrote:
I haven't worked with bytecode directly, but in the intermediate format
of the Soot compiler, lots of locals are created for things you don't
ever see in code (like intermediate results of nested expressions,
references to this, references to fields generated when you use
anonymous and local classes).
It would probably not require full compilation of the method to
determine which locals correspond to which variables in the code, but I
think it would be close.
This is kind of interesting.
For parameters the simple approach definitly would work.
See Java Virtual Machine Specification:
3.6.1 Local Variables
The Java virtual machine uses local variables to pass parameters on method invocation. On class method invocation any parameters are passed in consecutive local variables starting from local variable 0. On instance method invocation, local variable 0 is always used to pass a reference to the object on which the instance method is being invoked (this in the Java programming language). Any parameters are subsequently passed in consecutive local variables starting from local variable 1.
I think intermediate results are only on the stack, not in the local variable table, but that's really just an assumption. One would have to dig deeper.
Still, even if omnicode has a custom compiler, it does not compile the JDK itself. It runs on any JDK you supply.
So it must be possible top infer local variables without re-compiling the byte code.
Stephen Kelvin wrote:
I guess that CodeGuide semi-compiles the method you're currently
stepping in, on the fly, then uses the locals it generated to guess what
locals are in the actual JDK bytecode.
Should it not be possible to solve this problem by recompiling JDK classes (with debug info included) and including the recompiled jar into the project as a library?
I tried that with Swing classes, but to no avail. I made sure to place my library first (before JDK libraries). Am I missing something?
Thanks in advance for any ideas!
Tony
Tony wrote:
Yes. Let's say you have compiled Swing into swing-debug.jar. What you
need it to tell the VM that your jar is the main runtime one, not the
one in the Java installation direcotry. To do so, add the following
virtual machine parameter to the Run configuration:
-Xbootclasspath:/path/to/swing-debug.jar
That way the VM will first load the classes from you swing-debug.jar and
that way will skip the original swing classes.
It worked for me, I hope it will work for you also.
Greetings!