{"id":569893,"date":"2025-05-26T13:18:20","date_gmt":"2025-05-26T12:18:20","guid":{"rendered":"https:\/\/blog.jetbrains.com\/?post_type=idea&p=569893"},"modified":"2025-05-27T19:03:13","modified_gmt":"2025-05-27T18:03:13","slug":"sources-bytecode-debugging","status":"publish","type":"idea","link":"https:\/\/blog.jetbrains.com\/pt-br\/idea\/2025\/05\/sources-bytecode-debugging","title":{"rendered":"Sources, Bytecode, Debugging"},"content":{"rendered":"

When debugging Java programs, developers are often under the impression that they’re interacting directly with the source code. This isn\u2019t surprising \u2013 Java\u2019s tooling does such an excellent job of hiding the complexity that it almost feels as if the source code exists at runtime.<\/p>\n

If you\u2019re just starting with Java, you likely remember those diagrams showing how the compiler transforms source code into bytecode, which is then executed by the JVM. You might also wonder: if that\u2019s the case, why do we examine and step through the source code rather than the bytecode? How does the JVM know anything about our sources?<\/p>\n

This article is a little different from my previous posts<\/a> on debugging. Instead of focusing on how to debug a specific problem, such as an unresponsive app or a memory leak, it explores how Java and debuggers work behind the scenes. Stick around \u2013 as always, a couple of handy tricks are included.<\/p>\n

Bytecode<\/h2>\n

Let\u2019s start with a quick recap. The diagrams found in Java books and guides are indeed correct \u2013 the JVM executes bytecode.<\/p>\n

Consider the following class as an example:<\/p>\n

package dev.flounder;\n\npublic class Calculator {\n    int sum(int a, int b) {\n        return a + b;\n    }\n}<\/pre>\n
When compiled, the sum()<\/code> method will turn into the following bytecode:<\/p>\n
int sum(int, int);\n    descriptor: (II)I\n    flags: (0x0000)\n    Code:\n      stack=2, locals=3, args_size=3\n         0: iload_1\n         1: iload_2\n         2: iadd\n         3: ireturn\n<\/code><\/pre>\n
Tip<\/b>: You can inspect the bytecode of your classes using the javap -v<\/code> command included with the JDK. If you are using IntelliJ IDEA, you can also do this from the IDE: after building your project, select a class, and then click View<\/i> | Show Bytecode<\/i>.<\/p>\n
Note<\/b>: Since class files are binary, citing their raw contents would not be informative. For readability, the examples in this article follow the format of javap -v<\/code> output.<\/p>\n
Bytecode consists of a series of compact platform-independent instructions. In the example above:<\/p>\n
    \n
  1. iload_1<\/code> and iload_2<\/code> load the variables onto the operand stack.<\/li>\n
  2. iadd<\/code> adds the contents of the operand stack, leaving a single result value on it.<\/li>\n
  3. ireturn<\/code> returns the value from the operand stack.<\/li>\n<\/ol>\n
    In addition to instructions, bytecode files also include information on the constants, the number of parameters, local variables, and the depth of the operand stack. This is all the JVM needs to execute a program written in a JVM language, such as Java, Kotlin, or Scala.<\/p>\n
    Debug information<\/h2>\n
    Since bytecode looks completely different from your source code, referring to it while debugging would be inefficient. For this reason, the interfaces of Java debuggers \u2013 such as the JDB (the console debugger bundled with the JDK) or the one in IntelliJ IDEA \u2013 display the source code rather than bytecode. This allows you to debug the code that you wrote without having to think about the underlying bytecode being executed.<\/p>\n
    For example, your interaction with the JDB might look like this:<\/p>\n
    Initializing jdb ...\n\n> stop at dev.flounder.Calculator:5\n\nDeferring breakpoint dev.flounder.Calculator:5.\nIt will be set after the class is loaded.\n\n> run\n\nrun dev\/flounder\/Main\nSet uncaught java.lang.Throwable\nSet deferred uncaught java.lang.Throwable\nVM Started: Set deferred breakpoint dev.flounder.Calculator:5\nBreakpoint hit: \"thread=main\", dev.flounder.Calculator.sum(), line=5 bci=0\n\n> locals\n\nMethod arguments:\na = 1\nb = 2\n<\/code><\/pre>\n
    IntelliJ IDEA will display the debug-related information in the editor and in the Debug<\/i> tool window:<\/p>\n
    \"IntelliJ<\/p>\n
    As you can see, both debuggers use the correct variable names and reference valid lines from our code snippet above.<\/p>\n
    Since the runtime doesn\u2019t have access to the source files, it must collect this data elsewhere. This is where debug information comes into play. Debug information (also referred to as debug symbols) is compact data that links the bytecode to the application\u2019s sources. It is included in the .class<\/code> files during compilation.<\/p>\n
    There are three types of debug information:<\/p>\n