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.
[ JDK VERSION : 1.6.0_02 ] I have still in the latest build (2007-11-08_13-16-45) problems with the error badges. I here attach my specific use case on how I can always get error badges wrong. Use case: - I check out the project Hadoop from its repository (http://svn.apache.org/repos/asf/lucene/hadoop/) and create a new project with existing Ant-script. - I then "mount" the various (Java-based) sources and adjust each ones classpath, close the project creation wizard so the compilation goes on. - Now it marks several files in the package org.apache.hadoop.dfs in the project tree as containing errors... - Looking in those files I see that some of the errors are real because some files in that package (seemingly) do not compile (like NamespaceInfo or UpgradeObjectCollection). - When I now open one of these classes in the editor by double clicking on it in the project tree I can see that there are actually no errors... - Now, when I double click on another file in the project tree the error badge on the just opened class disappears... - But the error badges on all other marked classes still stay until I do the same double-clicking procedure there too. - When I now have "corrected" all wrong error badges, go back to the project properties, do some changes to the classpath, close the properties then after the re-conmpilation I get the wrong error badges again.
Honzo, this is the freeform project bug (changes on classpath) we have talked about last week.
First of all, thanks for the case - I can reproduce certain problems with the project. Max, this does not seem to be similar to the problem you are referring to. The problems here are caused by a few classes whose FQNs do not match their physical location (eg. org.apache.hadoop.dfs.DatanodeCommand is in file named BlockCommand.java). The current support for such classes has certain limits, leading into the problems described here. What happens: Imagine two files: A.java: class C {} B.java: class B extends C {} During initial scan (the rescan after classpath change is more or less equivalent to the initial scan), the IDE parses the source files one by one. In this case, if it starts with "B.java", it tries to resolve class "C", but does not find "C.java" (and it has no way to know that the class "C" is in file "A.java"), so error(s) are generated for missing class "C". Then file "A.java" is processed and class "C" found and recorded. So now if "B.java" is opened in the editor, class "C" can be found.
Any plan to fix in NB 6 ?
I have an idea on how to fix this, but no real fix yet. But the current idea seems too dangerous and complex for NB6.0 to me. The idea is to check for the class name/file name mismatch, and if detected, re-run the initial scan with the knowledge of physical location of all classes.
Lets try :) only delete mismatches and try recreate only mismatches
Unfortunately, I do not think that simple re-parsing files with error will be enough - the order of re-parsing is also important (and hard to detect). Imagine class D extending B from the previous example: the re-parse would need to ensure that "B" is re-parsed before "D", otherwise "D" will not be parsed correctly anyway. The only idea I have is to do one "initial scan" to find out the location of classes, clear the caches (sig files) and scan the given source root again. I hope it will be possible to make the first scan fast. Of course, a proper patch should ensure negligible overhead for source roots that do not contain these "misplaced" classes. I am currently trying to implement the fix, but I still think that the fix will be too risky for NB6.0.
How about provide menu action to re-run initial scan in NB 6.0
*** Issue 121890 has been marked as a duplicate of this issue. ***
Hopefully fixed: http://hg.netbeans.org/main/rev/cc99b9e71af9 http://hg.netbeans.org/main/rev/adb5a03e5fdc http://hg.netbeans.org/main/nb-javac/rev/0d373c9a8edb
*** Issue 127934 has been marked as a duplicate of this issue. ***