Community
Participate
Working Groups
Environment: Eclipse-201812 on Windows 7/10, Jre version for eclipse: Jre 1.8/Jre 1.10, Compilation target Java version: 1.7 Maven: 3.3.9 / 3.5.3 Post to the eclipse forums: https://www.eclipse.org/forums/index.php/t/1097192/ Everything works as usual when I open a .java file from an open project in the workspace. Following click-through of the referenced classes or called methods works fine with the .class files opened in Eclipse if the source-code is available in Maven repository. Setting a breakpoint in a .class file; work as expected. Breakpoint set. Debugging the app in Eclipse, it stops at the breakpoint, perfect! But Eclipse takes one minute or so to park the cursor to the line with the breakpoint. Now I have two files of the same class open in Eclipse. One is the .class file when I setup the break, which I can follow the click-though to open referenced classes or called methods to .class files in the same or different .jar files. The other one is open by the debugger when the execution stops at the breakpoint. This second file is different from the first file, it's like a file opened from History. You cannot follow click-though to open classes from method call. For example, the following line of code in the second file: MyType t = handler.process(a, b); You can click MyType to open the MyType.java or MyType.class file, but you won't get anywhere by clicking method call process(). You need to use the context menu to get what you want to see. Try it yourself, you'll understand what I mean. The debugger is very difficult to use, comparing to Oxygen.
Can you please attach a sample project?
Can you please disable Java -> Debug -> Use advanced source lookup and try again?
Uncheck "Use advanced source lookup" seems fixed the issue. But what is that option for? How does eclipse look for source code when it's checked?
@Igor, Can you look into this as this seems to work fine without Advanced Source lookup ?
harry sheng, please provide small standalone example project and exact steps we can use to reproduce the problem. The behaviour you describe is not expected, but I don't have enough information to explain what's going on.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
