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.

Bug 121561 - [60cat] Error badges in project tree still wrong
Summary: [60cat] Error badges in project tree still wrong
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Source (show other bugs)
Version: 6.x
Hardware: PC Windows XP
: P2 blocker with 1 vote (vote)
Assignee: Jan Lahoda
URL:
Keywords:
: 121890 127934 (view as bug list)
Depends on:
Blocks: 121950
  Show dependency tree
 
Reported: 2007-11-09 11:58 UTC by host
Modified: 2008-02-28 10:58 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description host 2007-11-09 11:58:24 UTC
[ 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.
Comment 1 Max Sauer 2007-11-09 12:26:44 UTC
Honzo, this is the freeform project bug (changes on classpath) we have talked about last week.
Comment 2 Jan Lahoda 2007-11-09 20:09:09 UTC
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.
Comment 3 _ theanuradha 2007-11-12 09:24:58 UTC
Any plan to fix in NB 6 ?
Comment 4 Jan Lahoda 2007-11-12 13:32:19 UTC
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.
Comment 5 _ theanuradha 2007-11-12 13:52:29 UTC
Lets try :)

only delete mismatches and try recreate only mismatches 
Comment 6 Jan Lahoda 2007-11-12 15:34:25 UTC
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.
Comment 7 _ theanuradha 2007-11-14 04:48:56 UTC
How about provide menu action to re-run initial scan in NB 6.0
Comment 8 Jan Becicka 2008-02-11 16:26:29 UTC
*** Issue 121890 has been marked as a duplicate of this issue. ***
Comment 10 Jan Becicka 2008-02-28 10:58:51 UTC
*** Issue 127934 has been marked as a duplicate of this issue. ***