I have just tested in release 6.7 and your scenario works there.

However it does not work when you keep the p.NewClass opened in the NB editor and modify it from other editor.

Dusan, can you have a look please?

Wow, you are right, the original scenario now works - wonderful!

I would like to ask what is the purpose of this bug. If my guess on the cause of this problem is correct, than this is a
scenario that was discussed many times in the past. It is also (to the best of my knowledge) unsolvable in java support
or parsing.api (see below), and maybe not truly fixable at all.

The problem is very simple: the indexing (either in java.source/gsf in 6.5 or in parsing.api in 6.7) adds filesystem
listener on each source root it processes. But, the filesystem refresh checks only files for which the FileObjects
currently exist in the memory (for performance reasons). So, if you modify a file externally, and there is no FileObject
for it in the IDE, the event never comes and the indexing "never" notices that there was a change and "never" updates
the index for the file. Of course, as soon as the "timestamp" check is executed on the source root (i.e. at worst on the
next startup), the index should be updated. There is (at least one) heuristic in place to mitigate this problem, but I
know only two real solutions: use some native mechanism (inotify) to listen on file changes and re-fire them inside the
IDE, or do a full timestamp check on window activated (either in filesystems, or in indexing). The later is totally
unacceptable (=initial scan on each window activated).

For java+ant, the timestamp check is executed on Clean&Build automatically, so it should be enough to invoke the clean
build to recognize external changes. Note that this is in hopes that the performance penalty will be minimal (as the
commandline compiler needs to stat each source file in the source root anyway, so the filenames/timestamps will likely
be in the OS caches).

The reason why it might in some cases appear to be solved in 6.7 is that the 6.7 indexing uses FileObjects, while 6.5
used j.i.Files. So, the indexing creates FileObjects for all source files, and until the FileObjects are GCed, the
filesystems check them for updates. So, the external changes in the unopened file may be noticed for some time after the
initial scan. But, as soon as the FileObject(s) is/are GCed, the behavior should revert to the 6.5 behavior.

The currently failing scenario is:

1. Have A.java and B.java both opened in NB
2. A.java has focus and the user is editing it in NB
3. B.java is modified externally
4. The external change is not reflected in the code completion until you focus (start editing) B.java in NB

My guess: the file object for B.java exists all the time but the file object does not fire anything since the file
object itself does not know about the external modification until someone asks for e.g. last modification time or something.

I am not saying that it is fixable - just saying that it is failing for the users where e.g. their files are modified by
e.g. external VCS commands (svn up, cvs up from the command line).

Your rhetorical question can be answered (IMHO) by this: Petr wants user action "Refresh" e.g. on each file or project
since he wants to be able to force the IDE to rescan something he knows was externally modified. Is it that crazy idea?
I don't know.

> I would like to ask what is the purpose of this bug

It was discussed in yesterday's t-team meeting that all situations when the index is not up to date (and as a result,
some features are inaccurate), should be treated as defects. That is the background for this report.

> Petr wants user action "Refresh"

Yes, I think this would be a reasonable solution, in the situation when we admit that we can not assure that the index
is always accurate and up to date wrt. the sources.

I suspected that this might be about the Refresh action, but I was puzzled, as the original report did not mention it
(and, (too) strictly speaking: the original steps to reproduce will not work even with the Refresh action, and the
Refresh action can be replaced by Clean&Build in the original scenario). Also note that the Clean&Build heuristic is
outcome from one of discussions on this theme almost a year ago.

I am personally not a big fan of the Refresh action - it is not difficult to write it, but it is probably difficult to
make it acceptable for the users (it should not clutter the UI too much, should be easy to find, etc.) The beauty of the
Clean&Build is that for many (most?) users it is the natural thing to do. But I see no technical reason why the Refresh
action couldn't be introduced (note that such action probably should not be a "Java support" action).

I think the biggest problem of the "Clean and Build" approach is the discoverability and intuitiveness. We had a lot of
complaints about incorrect error badges in 6.5, and it sounds like the solution to that should be to do Clean and Build,
right? Yet, many users kept reporting this problem, rather than doing Clean and Build. Maybe Refresh would be a more
obvious remedy for many users, especially those coming from Eclipse.

> ... the Refresh action, but I was puzzled, as the original report did not mention it

I did not want to push a particular solution, I am open to other solutions if there are any.

Jarda now created a reproducible issue with a unit test (168237), which covers the use case I had in mind. So feel free
to close this as a duplicate of issue 168237.

Ok, marking as duplicate.

*** This issue has been marked as a duplicate of 168237 ***