> How does this differ from debugging any other VM?
You can run a plethora of languages on the JVM and get full debugging support - i.e. an application crash will show you where in your code things exploded, rather than showing you a trace into generated code (or more applicably in the case of the JVM, bytecode).
> Debugging a Java or a C crash is infinitely worse, since instead of comparatively pretty symbols and a verifiably correct trace, you have a vector of bytes where your stack is supposed to be, and any number of threads running third party libs that could have written all over your frame pointers, and instead of semi-structured code you have a few thousand flattened basic blocks, devoid of any type information, absolutely swamped in gotos and boilerplate prologues/epilogues.
I don't have a huge amount of experience of debugging in C, so I cannot comment on how accurate your statement is for C, but for Java it is absolutely not true. That scenario bears no resemblance at all to debugging Java applications.
You can run a plethora of languages on the JVM and get full debugging support - i.e. an application crash will show you where in your code things exploded, rather than showing you a trace into generated code (or more applicably in the case of the JVM, bytecode).
> Debugging a Java or a C crash is infinitely worse, since instead of comparatively pretty symbols and a verifiably correct trace, you have a vector of bytes where your stack is supposed to be, and any number of threads running third party libs that could have written all over your frame pointers, and instead of semi-structured code you have a few thousand flattened basic blocks, devoid of any type information, absolutely swamped in gotos and boilerplate prologues/epilogues.
I don't have a huge amount of experience of debugging in C, so I cannot comment on how accurate your statement is for C, but for Java it is absolutely not true. That scenario bears no resemblance at all to debugging Java applications.