tbitonti / jakartaee-prototype

Other
0 stars 9 forks source link

Debugging transformed code #100

Closed tbitonti closed 4 years ago

tbitonti commented 4 years ago

This issue is to capture the results of investigating how usable transformed code is to debuggers.

Current package rename rules update both class reference information and string constants. This should update the in-class information to cover data used by the debugger. The question remains as to how usable the transformed classes are within debuggers. Line number information is preserved by the transformation, so walking the original code should mostly work. However, because of the transformation, the code won't match exactly.

bjhargrave commented 4 years ago

I think this means I need to work on Bnd's support for the SourceDebugExtension attribute. The JVMS treats the value as a byte array but there must be an interop specification some place which would parse the information into something the transformer could mutate.

I opened https://github.com/bndtools/bnd/issues/3930 for this.

bjhargrave commented 4 years ago

Can you provide more details? I am not sure anymore that the SourceDebugExtension has anything to do with this since I don't see it in some example class files.

volosied commented 4 years ago

I spent some time testing the debugger in Eclipse with a few of the transformed bundles (mostly jsp and webcontainer), created through this prototype, in Open Liberty. Overall, it worked well on the transformed classes:

Although we do not transform string constants often, I inspected one scenario where we did. The source code had "/javax/servlet/jsp/resources/web-jsptaglibrary_1_2.dtd", but, the debugger displayed the variable as the transformed string, "/jakarta/servlet/jsp/resources/web-jsptaglibrary_1_2.dtd".

As Tom suggested, I also suspect there may be issues where the lines don't match up based on the kind of transformation (or maybe the amount for a particular file), but this doesn't seem to present any issues so far.

The only limitation I found is when you try to jump into the javax source when the transformed application uses jakarta. The same issue occurs vice versa. This is the expected behavior since packages must match up. This was tested with the servlet API. However, by having both the Jakarta API and the Javax API sources on hand, I was still able to step into either one without issues.

Additionally, the same problem described above occurred when I debugged a transformed jar (the packages themselves were changed) with the JVM option (-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=7777). My breakpoint in the source was not picked up unless the packages matched up.

Issues may be identified as more people debug these transformed classes, but the transformation doesn't seem to pose any trouble for debugging.