Enable debugger to detect when there is a mismatch between source code and class being debugged
- Detect mismatch between the source code and the class bytecode being debugged
- Allow for IDEs to identify through Debugger API such mismatch, enabling development of extensions
To increase development productivity by avoiding developers on wasting time debugging the wrong source code
Developers often find themselves debugging a Java application attached to their IDE, where the source code used to compile the bytecode being debugged is similar, but not the same. This leads to time wasted in understanding why some things behave differently, and sometimes developers blame the JVM, or the application server, or something in the runtime environment.
By providing a fingerprint to the source code used to compile a bytecode, when javac is configured to do so (example: -g:sourcefingerprint), and injecting that fingerprint into the bytecode, the Debugger API can then expose such information to IDEs and Debugger agents. The jdb command and the Java Debug Interface API may need to be extended to add such information.
A test use case to validate this JEP is in the form of:
- compile a Java class
- modify the source code
- run the bytecode initially compiled
- debug the application
- identify the mismatch that source code has been modified
Debug with jdb.
There is a risk of the source code match the bytecode, but not inherited classes, which means not only the class being debugged but its structure and inherited graph must also match.
The fingerprint must consider multiple data from the source code in order to be stringent:
- sourcecode checksum
- Java class structure
- inheritance graph
It may be required to considered other form of data to build the fingerprint.
Beyond the jdb tool and the Java Debug Interface, there are no other identified dependencies.
The checksum should not include anything that is not in the source file used to compile the class. So a simple checksum of the source file is better.