[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    JEP: Allow debug tools to detect mismatch btwn sourcecode and bytecode
From:       Bruno Borges <bruno.borges () oracle ! com>
Date:       2014-11-29 22:45:22
Message-ID: 547A4C81.4000506 () oracle ! com
[Download RAW message or body]

Hi all,

Based on a common incident that happens not rarely among developers, and 
as recently felt by Martijn Dashort [1], it seems to be a good idea to: 
"Enable debugger to detect when there is a mismatch between source code 
and class being debugged" (thanks to Stuart Marks for the excellent 
problem statement [2]).

[1] https://twitter.com/dashorst/status/538329707549560832
[2] https://twitter.com/stuartmarks/status/538722163700674561

So I came up with the following JEP draft, and I'd like to have your 
input in this matter as well any comments, suggestions, etc.

--- JEP DRAFT BEGIN ---

Summary
-------
Enable debugger to detect when there is a mismatch between source code 
and class being debugged

Goals
-----
  * 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

Motivation
----------
To increase development productivity by avoiding developers on wasting 
time debugging the wrong source code

Description
-----------
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.

Testing
-------
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.

Risks and Assumptions
---------------------
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.

Dependences
-----------
Beyond the jdb tool and the Java Debug Interface, there are no other 
identified dependencies.

--- JEP DRAFT END ---

-- Bruno Borges // +5511995649058 LAD Principal Product Manager Exalogic 
| Cloud | CAF | Java
[prev in list] [next in list] [prev in thread] [next in thread]