netbeans
netbeans copied to clipboard
Error parsing file (red mark) when having 2 or more java classes in the same java file or inside the same package, that share same class name (e.g after cloning/copying)
Apache NetBeans version
Apache NetBeans 13
What happened
Error parsing file (red mark) when having 2 or more java classes in the same java file, inside the same package, that share same class names (e.g after cloning/copying). If public class then we give the file name of the class. If other classes (more than the main one) exist in the same java file (nested or separate non public), then we get this error without any guidance to resolve the naming conflict. Background scanning of projects could then be triggered, and this scanning time period, will be long.
How to reproduce
Create a public class, rename the New Class to the class name Create a non public class inside the same file, nested and/or separated. Copy Paste the Java file to the same package from projects list. Let it live inside a project, sooner or later it will appear.
Did this work correctly in an earlier version?
No
Operating System
windows 7
JDK
17
Apache NetBeans packaging
Apache NetBeans provided installer
Anything else
No response
Are you willing to submit a pull request?
No
Code of Conduct
Yes
this sounds like a very specific issue which rarely occurs. I am not sure if the time investment would be worth it to teach the parser to deal with invalid files containing duplicated class names. But contributions welcome.
It is not critical for sure. Files are not invalid if stand alone. Only if there is an other file with same class name in the same package. It would be ok if we could get a better message to focus on what the problem is. I figured this out when opening the same project in intelij, the error message was pointing to the names, here this is just a parsing error without details.
This error appears at random times, but when triggered activates background scanning of projects that takes much time to complete and sometimes an other error like this one can be found, I guess the background scanning does not scan everything at once.
It would be nice to see a better approach on multi-class files in the same package. The red mark appears only on file names in project/package files list, never inside the actual text of the file. Random is also which one of the involved files will be marked (between 2+ conflicting files in the same package).
To sum up, this error has random behavior witch is odd, it appears to be in conjunction with background scanning of projects that sometimes finds or misses the same conflict, and marks randomly the parsing file error to a file.
May I ask if your current problem has been resolved?
I have deleted/renamed all those same name classes, so I do not know if it this rare issue still exist, if other changes have been placed around source, if someone can create some classes that are being described in "How to reproduce" hold them there in a temp package and never blow up, I guess it is solved, if not you can keep the package until it shows the error and confuse the scanning mechanism. There is not an immediate error mark if I remember correctly, but it did came up and stayed there after a project reopen.
I have encountered a problem similar to yours. After a long period of project scanning, strange code parsing errors may occur. And it's not always the case with every scan, it's sporadic.
Experimenting with some same name classes gives again the error, deleting them brings system back to no error state. I also have to note that even "refactoring" does not work when classes with the same name belong to the same project (or package, I am not sure). But issue could be related, refactoring the class in the second directory, changes code in the other one and this should not happen, "refactor" skips the target class and refactors the first one.