This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Created attachment 156963 [details] log file I have seen this hundreds of times during the last more than 10 years using NetBeans. I have reported this many times. It is now time that the NetBeans acknowledges that this is a fundamental issue that obviously cannot be fixed in the way the NetBeans team thinks it should be addressed or not addressed. Otherwise I would not have the problem now. I have replaced code in a single class within the editor and while the class is still valid and the maven build succeeds, code as shown in the source is not executed, and the debugger is out of sync. I have a statement in the class System.out.println("Something"); The debugger steps over it as if it was executed. But it is not executed. Otherwise the result would be shown in the console. What is NetBeans actually executing? Apparently an old version of the code. The debugger steps into comment as if there was actually code there. The reason for extreme frustration is that in such a case, where some yet unknown component fails in an unexpected way, the IDE fails to help me find the problem. I can see that the IDE is failing, but I cannot clean it up. I stop the debugger session and clean and build the project. Debug again. If I set a breakpoint on a valid line of code then I get a broken breakpoint. I can't fix this. I don't know what code is actually running - the running code seems to be unrelated to the source code. I need a way to tell the IDE to clean itself up. Eclipse has this. But NetBeans thinks it is smarter and does not need this. Wrong. The only way I see how the IDE can recover from this is to close it and delete the cache. Wait for an hour until the cache is re-built, maven index is downloaded and re-build? Why can't I select the class and let NetBeans clean it up?
I rename the class then set a breakpoint on the first line of a method. Not able to submit breakpoint LineBreakpoint MyClass2.java : 30, reason: No executable location available at line 30 in class Myclass2. Invalid LineBreakpoint Myclass2.java : 30 For a change, this time the breakpoint is shown in the editor intact although it is broken. So even renaming the class, which should have cleaned it up, has not cleaned it. The point I am trying to make again, is, that whatever the root cause of this is, there is no obvious way to recover.
I have deleted the cache directory and re-started the IDE. Still the same problem.
I have installed the latest release candidate RC2. The problem persists.
The problem was that a duplicate source file exists in the standard maven test hierarchy (by mistake) and that is the one that is executed in a test. However the breakpoints are on the class in the main source file and they break if the source is not the same. Interestingly, the Go to Type dialog shows the 2 files separately. However the debugger is not aware of the distinction. I do not have an opinion on how to solve this from the IDE perspective because in a different scenario other people might want to use this as a trick to override 3rd party classes.
It seems that the core of this problem that you described in the last comment can be different from a possibly more generic problem that you've described initially. The problem with the breakpoint submitted to a different class (loaded sooner on the class path) is solved in NetBeans when we can detect this from the class path. When you create two projects, both contain an identical class, one depends on the other, but the breakpoint is submitted in the class that is not loaded due to the other being sooner on the class-path, then the breakpoint is ignored and you get a message like this in the Debugger Console window: Not able to submit breakpoint LineBreakpoint JavaApplicationClass1.java : 18, reason: Breakpoint's source file does not belong into the preferred source root '/tmp/NetBeansProjects/JavaApplicationClass1/src'. Invalid LineBreakpoint JavaApplicationClass1.java : 18 When I submit breakpoint into the correct "preferred" path according to the project dependencies, but then I confuse the projects dependencies with adding a third module containing the same class: -Xbootclasspath/a:/tmp/NetBeansProjects/JavaApplicationClass3/dist/JavaApplicationClass3.jar Then the breakpoint is hit in the editor, in the source file from JavaApplicationClass1/src, but the class was in fact loaded from JavaApplicationClass3. There can be multiple ways how to confuse the simple "classpath" approach. We can try to solve the bootclasspath case, but your case with Maven test hierarchy is likely yet something different. Is the project you're debugging available somewhere, or can you provide a test case?
Created attachment 156984 [details] Simple test case This test case has the same structure as I had in my project. The behavior is different though. When debugging via run focused test method testExecute() which is the same as I did in my original project, then on discovery of the invalid breakpoint, debugging stops. In my original project, where the duplicate class had more code, the debugger did not stop. I could see confused stepping over comments etc.. I found a maven plugin that is apparently warning of duplicate classes in the classpath: https://github.com/basepom/duplicate-finder-maven-plugin . But I don't want to distract. Perhaps you have some ideas what may be done from the IDE perspective.