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 161980 - [67cat] Stale error indicators
Summary: [67cat] Stale error indicators
Status: RESOLVED INCOMPLETE
Alias: None
Product: java
Classification: Unclassified
Component: Source (show other bugs)
Version: 6.x
Hardware: Macintosh Mac OS X
: P2 blocker with 1 vote (vote)
Assignee: Jan Lahoda
URL:
Keywords:
: 161981 (view as bug list)
Depends on:
Blocks: 121950
  Show dependency tree
 
Reported: 2009-04-05 13:15 UTC by big_al
Modified: 2009-11-05 15:23 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
200904091401 Log output during problem (39.22 KB, text/plain)
2009-04-10 13:13 UTC, theshadow27
Details

Note You need to log in before you can comment on or make changes to this bug.
Description big_al 2009-04-05 13:15:31 UTC
[ JDK VERSION : 1.6.* ]

After installing M3 I opened a Maven project with multiple modules.
At first it complained about a lot of missing java.* classes. This
was my fault as I forgot to update the JDK setting (netbeans.conf)
from JDK 1.5 to 1.6. I shut down NetBeans, updated the JDK setting to
use 1.6 and restarted NetBeans. 

Problem 1) All the error indicators stayed on the projects even
though the java.* classes were now available. I had to manually open
each of the files with an error indicator for them to go away. 

Problem 2) After updating sources from subversion the individual
modules didn't detect changes in the other modules - giving a lot of
error indicators again. This time however, it didn't help to simply
open the files. After 10 or so minutes the error disappear from the
file (seems to have recognised the changes) but the error indicators
stay (now removable by making a change to the file and saving it).

For both problems I've tried executing clean and build but to no
help. Clean and build compiles the code without a problem in the
output console.

Isn't there a way to force NetBeans to throw away the stale error
indicators and scan the project from scratch?
Comment 1 big_al 2009-04-05 13:18:27 UTC
*** Issue 161981 has been marked as a duplicate of this issue. ***
Comment 2 Rastislav Komara 2009-04-07 10:37:41 UTC
Please provide messages.log and exact steps to reproduce. Is this caused by opening maven project only? Or it happens
with any project type?
Comment 3 matthies 2009-04-07 20:30:27 UTC
This is probably the same general issue as issue 104665, which I still regularly encounter. NetBeans doesn't detect all 
changes that might require error markers to be re-synchronized. In some cases this is not surprising, in particular in 
the case of changes by external programs. In other cases there seem to be bugs caused by complex dependencies and 
asynchronous operations, for example with large cross-project refactorings or cross-project CVS updates. The "auto-
fixer" solution of issue 104665 works in many cases (of course it still takes time, and the n seconds wait has to be 
done for each affected project at least), but not in all. For example sometimes the "auto-fixer" only fixes a small 
subset of the source root. When the "auto-fixer" doesn't work, I usually solve the problem by closing NetBeans, 
deleting ${userdir}/var/cache and restarting NetBeans (and taking a coffee break while the world is being rescanned).

My feeling is that it's not reasonable to expect NetBeans to get the synchronization right under all circumstances. It 
would require the Java source code dependency model to be completely bug-free, the internal class index to always 
correct and up-to-date information, all operations on Java files & libraries to properly notify all the changes they 
made, asynchronous filesystem operations to always be correctly synchronized, and Java files & libraries never be 
modified by external programs. IMO this is an illusion.
Comment 4 big_al 2009-04-07 21:12:40 UTC
@matthies I agree. However, the stale error indicators seems to have got worse post 6.7M2. Ideally I would like a way to initiate a reset of the cache from 
within NetBeans. I would be happy with it taking a few minutes to drop the cache and reprocess the files. Under all circumstance a reprocessing of the files 
ought to kick in when updating from version control.

@moonko  I only work with Maven projects so I wouldn't know if it also affects NetBeans Java projects.  
Comment 5 eruvel 2009-04-07 22:41:03 UTC
I have the same issue when just editing a java module. Netbeans doesn't recognize the change unless I do a diff with the
svn repository
Comment 6 theshadow27 2009-04-10 03:39:00 UTC
This is all project types, and it's not just errors. Classes will go "missing" for no apparent reason, and as big_al sais it has been getting worse. In 
200904070200 and 200904090200 (haven't gotten to 1401 yet):

For extended periods of time (not just a few seconds, 2-5 minutes) an entire class will go "missing" from a Java project, such that other classes which 
reference it show an error, the .class file is not built, and it is not bundled in the .jar/.war during build. It is possible to fix it by opening the "missing" file in 
the editor, making a change, saving it, then going back to the file with an error, making a change, and saving that as well. While that fixes one error, a 
different class will do the same thing within a minute or two.

As matthies points out, it's just not doing what it's suppose to. For a "extreme case" test, I performed the following steps:

1) hdid -nomount ram://2097152 (1024mb) to mount a ram disk
2) Format with HFS+ and copy the latest (20090409) to it
3) use the following default options in netbeans.conf:
   netbeans_default_options="-J-server -J-d64 -J-Xss64m -J-Xms1024m -J-XX:MaxPermSize=2048m -J-Xmx2048m -J-Dnetbeans.logger.console=true 
-J-ea -J-Dapple.laf.useScreenMenuBar=true -J-Dsun.java2d.noddraw=true -J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled -J-
XX:+CMSPermGenSweepingEnabled -J-XX:CompileThreshold=1

However, even with nearly ideal circumstances and unlimited resources, the OS on a SSD, the entire NB directory AND the project directory in DDR3 
memory, I get the same problem. The "clean and build" action does nothing, but if I go in to the editor of the "missing" file, and manually compile, then go 
back to the "broken" file, the error goes away. As soon as the one error goes away, another one comes up, in a different package. 

What data do you need to track down this problem?
Comment 7 theshadow27 2009-04-10 13:13:38 UTC
Created attachment 79883 [details]
200904091401 Log output during problem
Comment 8 theshadow27 2009-04-10 13:28:14 UTC
Actually on further testing, this is only a problem for me on Web Applications. Java class libraries and Java terminal applications seem to behave well.
Comment 9 Jan Lahoda 2009-08-20 09:58:06 UTC
Reassigning all moonko's java/source bugs to myself.
Comment 10 matthies 2009-08-20 13:39:39 UTC
Updated TM.
Comment 11 Peter Pis 2009-09-03 08:57:29 UTC
Requested info added. Removing Incomplete.
Comment 12 Dusan Balek 2009-09-18 08:26:32 UTC
Could you please try to reproduce the issue in the current dev build? Many bugs concerning wrong error indicators have
been fixed in the last couple of weeks. Thanks.
Comment 13 Jiri Prox 2009-11-05 15:23:23 UTC
Please try newer build and let us know is the problem is still reproducible
thanks