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.
For the last month or so, it I am constantly seeing red underlines under correct code in the editor. The typical pattern is that I type, say foo = getMyFoo(something) (assume that's fine, parsable code). It will end up getting error underlining. When I move the mouse cursor to the margin, the error always seems to be some partially typed text. It's like the parser psychically knows when I am about to make a line into legal Java and decides just before I do is the perfect time to update the error highlighting. This is severe enough that my CVS diffs often have random whitespace in them from hitting the space bar on perfectly good lines to force them to be reparsed so I can see if there really is a typo. I have suggestion that might help, *if* you can make the decision about when to reparse on the event dispatch thread (do the parse on whatever thread you want): I assume there is either a timer or something that triggers reparses. Maybe it is just the document changing. But something you could do when deciding to update highlighting is: long time = System.currentTimeMillis(); if (time - EventQueue.getMostRecentEventTime() < SOME_THRESHOLD) { //dont reparse, or start a timer and check //the length of time since the last event later What this should do is make sure that you *don't* do a reparse until the user has stopped typing for a while.
It seems like the timer is scheduled to update a result of the parsing task scheduled for the first change (in document) and it does not take into account scheduled tasks for later changes. I will look at it.
*** Issue 39004 has been marked as a duplicate of this issue. ***
The easiest way to demonstrate the problem: Start with some legal line of code like if (foo == getValue()) { ^ place the caret where I put the ^ start typing - you want to change the line to if (someValue == b && foo == getValue()) { You will get error highlighting that persists on the line. The annotation will say something like it cannot recognize the symbol "somfoo". And it never notices that the text changed after the parse, so the annotation just stays there until there's a save or some other key typed on that line. I'd say that when a document *begins* changing is exactly the wrong time to start trying to validate it - you want to parse it for errors when it has just *stopped* changing for some small amount of time. As a bonus, this means that the parsing will not be happening when the user is typing, which may have performance benefits.
Tim, >I'd say that when a document *begins* changing is exactly the wrong >time to start trying to validate it - you want to parse it for errors >when it has just *stopped* changing for some small amount of time. This is what we are doing from begining. BTW: This 'small amount of time' is controlled by Tools-Options->Editing->Java Sources->Automatic Paring Delay
Yes, I debugged the code and it works properly. The timer is rescheduled after each change in document and the parser is started if the document is not touched during the delay.
This might relate to issue #39805. Tim, I am not able to reproduce what you have decribed so I would appreciate if you could update your sources and try if it helps also in your case. Thanks
It seems better but not perfect - it may be related to problems with annotations in the editor not getting repainted/cleared. Also may have to do with the Navigator module doing its own reparse via the java source API - AFAIK our parser is not intelligent enough to queue such things - I once convinced the parser to create an endless loop inside a HashMap's internal structure by starting a parse at the wrong time on an SMP machine.
Could you be more specific what is still being wrong? I know the parser is not perfect but I certainly do not think it gets better for nb 3.6. Maybe MDR stuff will bring something more clever. Tomas could know more.
This was fixed.