java - Understanding Eclipse debug source lookup with dynamically compiled and loaded code -
for dislike reading long sentences:
i preface noting have specific question here related eclipse debugger source lookup in conjunction remote debugging. in order provide more localized picture of experiencing , why information relevant, provide background context below. knowing average so'er quite lazy , down-vote immediately, urge read actual question. might find not broad or localized had thought.
background info:
i have java framework meant run external scripts. this, use combination of classloader , system java compiler compile .java "script" files not exist on project's build path. of works, compiler black magic , all.
the inherent complication externally loaded code difficulty debug. have addressed using remote debugging feature of java runtime.
so, have debug configuration attaches executable jar, has directory external java scripts on source lookup path. this worked while.actually, never worked properly, had scripts accidentally on build path. confusingly enough can put breakpoints in scripts, , debugger stops there (consistent line number, -verbose:class logging , all). understanding how eclipse finds source files help, though. majority of eclipse documentation comprised of user manuals, after all.
what suspected had accidentally duplicated script files, , confused source lookup out-of-sync source file. not case, have since removed duplicated files , eclipse still unable find source.
what i've tried
- double, triple, quadruple checked source lookup paths ensuring includes every relevant directory
- enabled/disabled search subfolders
- enabled/disabled search duplicates
- using absolute path directory instead of relative workspace path
workaround
the workaround here add script files onto build path of project, unacceptable me.
what i'm doing now
i crawling way through eclipse open source project base repository looking answer. eclipse, turns out, pretty big project.
question
can provide accurate algorithmic representation of how eclipse source lookup works?
knowing this, possibly figure out way force eclipse debugger use correct path using reflection. far know, there no technical limitation prevents dynamically compiled code being debugged. know because breakpoints suspending threads expect them to, the source code doesn't seem want load :(
related research: seems this might linked how class defined null codesource location, apparently proper thing when dynamically compiling code memory give null arg... the question still stands how/why matters eclipse's debugger.
update 4/22 3:30: pursued codesource solution linked above. now, seeing class being loaded proper file path location -verbose:class switch, source lookup still failing. breakpoints still caught, greeted familiar source not found red lettering.
updated 5/6 3:15: pursued javap solution discussed in andrew's answer. turns out, source file attribute in .class bytecode matches file exist on source lookup path. confuses me, because hints towards folder hierarchy having influence on source lookup. however, have created "phantom" package hierarchies representing "true" packages(as defined @ top of .java files) , moving source files folders, source lookup still failing when add paths source lookup path. additional insight additional factors play source lookup huge.
i have bit of experience in area, having done work on debugging dynamically compiled groovy scripts though jdt. never got work perfectly, , think limitation of jdt, never designed handle dynamically compiled code.
tldr: guess dynamically compiled scripts have incorrect source file attribute in byte code. attribute set in class file compiler. see https://en.wikipedia.org/wiki/java_class_file
your confusion, think, debugger correctly stops @ breakpoints set in scripts, ide cannot load source. confusing of course, there explanation this.
breakpoints handled vm , vm keeps track of them through qualified name , line number. allows breakpoints hit regardless of classloader loads class file, can lead confusion if multiple class files loaded through different classloaders same qualified name, different source code. algorithm determining when stop vm has nothing looking source code when vm stops.
looking source code handled ide. since in statically compiled world, source file name may not match class name (inner classes, anonymous classes, etc). class name cannot used source file.
here simplification of ide when stops @ breakpoint:
- find class file @ breakpoint
- get source attribute
- find source file in source lookup path matches name of source attribute
- use heuristics if multiple source files of same name found (i think ranking in source lookup tab)
- return appropriate source file.
(caveat, think source attribute simple name of source file (ie- no directory), think ide converts package name directory structure part of lookup, might wrong that).
so, lookup fail if dynamically compiled script not have proper source attribute. can check theory looking @ byte code. have somehow compile script , save bits disk. can run javap -v myscript on it. bet problem. have seen happen before in other dynamically compiled languages.
Comments
Post a Comment