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.
By happenstance, the Java package mypkg and the source files mypkg.* landed in a directory .\mypkg\mypkg\. Compiling was still possible, there were no clues whatsoever about this "accident". When debugging and having set some breakpoints, the debugger behaved in a very bizarre way, and I landed in some JDK package deailing with class load and thread management. Confusion was huge, and it took some time until I found the reason (fixing was peanuts, of course). I am not sure whether this is a true bug, maybe not, but this report certainly adresses user friendlyness. For somebody like me, having used NetBeans for two months only, it simply was pure luck of getting out of this "scrub" without grief and despair.
I understand that the described error state was a source of a big confusion. However, IMHO this is rather a problem of Java integration than debugger. I have problems to duplicate such error state and reproduce the associated problems. It would be best of you would be able to describe steps that lead to such state. It's likely, that debugger got class files with "mypkg.mypkg" package, but there was only "mypkg" in the source files. From debugger's point of view, there's no match and thus it's expected that you were not able to debug the user code. Then debugging works only in JDK classes, where the source and binary classes do match. Moving to Java, to evaluate if there can be a way to detect such inconsistency.
The package was "mypkg" while the source structure was "mypkg/mypkg", right? If true: The java class fqn is always the one implied by the package. The non public class in package which does not correspond to disk structure is a java valid class and can be compiled. We show a warning about wrong practise on package AST. >debugger got class files with "mypkg.mypkg" package, but there was only "mypkg" in the source files. Which is valid for non public classes, use SourceUtils.getFile() which correctly maps java types to resources.