[ https://issues.apache.org/jira/browse/GROOVY-4063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16674555#comment-16674555 ]
Eric Milles edited comment on GROOVY-4063 at 11/4/18 11:29 PM: --------------------------------------------------------------- GROOVY-8742 seems related. Line number information in class file is the reason the breakpoint does not hit. When compiling without "indy", there is a fast-path conditional added and this generates two paths through the code and both receive line number information for the visible source. This confuses the debugger. was (Author: emilles): GROOVY-8472 seems related. Line number information in class file is the reason the breakpoint does not hit. When compiling without "indy", there is a fast-path conditional added and this generates two paths through the code and both receive line number information for the visible source. This confuses the debugger. > Debugger Step Into doesn't work in Groovy-compiled classes when stepping > filters are applied > -------------------------------------------------------------------------------------------- > > Key: GROOVY-4063 > URL: https://issues.apache.org/jira/browse/GROOVY-4063 > Project: Groovy > Issue Type: Bug > Components: class generator > Affects Versions: 1.6.7, 1.7.0 > Reporter: Peter Gromov > Priority: Major > Attachments: debug-test.tar.gz > > > Reproduced in IntelliJ IDEA 9, GroovyEclipse 2.0 and JSWAT 4.5, therefore the > problem is probably in Groovy itself. > Stepping class exclusion filters are set to ignore everything from Java and > Groovy internals: groovy.*,org.codehaus.groovy.*,java.*,sun.*,org.apache.* > {code} > class Some { > static void meth() { > println "Method is called." > } > public static void main(String[] args) { > meth() // breakpoint here > } > } > {code} > Run to the breakpoint in 'main' method. 'Step into'. There's a very long > pause (presumably JVM applies the filters to all the underlying groovy > internals), the message is printed and the program exits. Breakpoint is not > hit. > Now put the breakpoint to the 'println' line in 'meth' and repeat stepping > into. This time the debugger stops at it. > Stepping worked in earlier Groovy versions (e.g. 1.5) and stopped in 1.6. > Therefore I suspect it to be somehow mystically related to class generation > (or the libraries used, whatever) -- This message was sent by Atlassian JIRA (v7.6.3#76005)