*** Issue 51719 has been marked as a duplicate of this issue. ***

*** Issue 51721 has been marked as a duplicate of this issue. ***

Can also apparently grab focus from external applications, even after
the dialog closes. Note also that the rescan occurs just as much for
in-IDE builds, which can also be a problem if you have switched to
another app while the build is running.

One thing which is curious is that if project A depends on project B,
i.e. CP(A/src,COMPILE) = B/dist/b.jar, rebuilding B causes a rescan of
b.jar for A's benefit, even though all the sources for b.jar are in
B/src and have not changed during the build. This seems to be an
artifact of the fact that the javacore infrastructure ignores
SourceForBinaryQuery in this respect: both B/src and B/dist/b.jar are
*independently* scanned (have their own indexes). If javacore were to
somehow skip (re-)scanning for b.jar, just using B/src's index
instead, this problem would probably not appear in normal usage - only
if your build actually recreated a JAR file with no source
association, which is never done by the default targets in j2seproject
and relatively rare even in customized build scripts.

A general UI rule is that dialogs should not pop up asynchronously,
i.e. not in direct (~ 200 msec) response to a user input event.
Classpath scanning dialogs do not violate this when they occur in
response to a user-initiated change in settings (e.g. open a project,
or closing a project properties dialog after making changes to the
classpath), but they do violate this rule when they occur in response
to timestamp changes on classpath JARs.

I am not sure what to suggest, since the current locking model for
MDR/JMI seems to make it impossible to do background scans without
potentially blocking EQ during common user actions or even editor
repaints. Perhaps it is possible to do synchronous (in-EQ) scans of
limited chunks of the classpath (e.g. at most 50 *.class files, or at
most 10 *.java files), leaving EQ open for user interaction (perhaps
running selected scans synch as needed) and repaints between bursts of
activity. This would require that locking be per class, not per
database or global, but from what I know of the JMI storage and
indices, that would not be a big problem. It would mean that the
dreaded classpath scanning dialog would go away and be replaced by
e.g. status-line notification that scanning was in progress; during a
scan, it would be possible to work with the IDE, but not at full speed.

Another possibility is to use a nonnative dialog inside the MDI window
to indicate classpath scanning. This is possible using a glass pane, I
think. You could dim (alpha-blend) the rest of the UI behind it to
make it obvious that you have to wait. Functionally it would work
exactly as the current dialog does, but would not interact with the
native window manager's idea of the current focussed window, which
would be an improvement. Ideally o.o.awt.DialogDisplayer would have an
option to display a lightweight rather than native dialog.

> If javacore were to
> somehow skip (re-)scanning for b.jar, just using B/src's index
> instead, this problem would probably not appear in normal usage

That's how we plan to fix this.

> I am not sure what to suggest, since the current locking model for
> MDR/JMI seems to make it impossible to do background scans without
> potentially blocking EQ during common user actions or even editor
> repaints.

Not true for scanning - the scanner releases the transaction anytime
it finds out the EQ is waiting for it and reacquires it when the EQ is
done. So, we can do it on the background. The reason why we are not
doing it on the background is we did not make a special case for
scanning in response to a timestamp change - i.e. the same code is
used for the scan during the ide startup and the scan during the
timestamp change.

Waiver approved for 4.0.

Fixed.

  Revision  Changes    Path
  1.12      +11 -15   
java/javacore/src/org/netbeans/modules/javacore/classpath/MergedClassPathImplementation.java
 

I still see the same behavior. Scanning progress dialog pops up when I
run "cvs update; ant buildnozip" externally. It pops up both during
the cvs update (when java files are modified on disk) and during the
external ant execution (when jars on disk are modified).

We have fixed unnecessary scanning of class files if there are sources
on the classpath. So now you get the scanning dialog only when you
change jars that do not have corresponding sources (e.g. jars from
external binaries). I don't see how we can fix this unless we make the
scanning non-modal. As we agreed at the last performance meeting, we
will not make it non-modal for 4.1. I suggest lowering priority of
this bug to P3 since the most common problem (with scanning jar files
that are result of compilation of project sources) is fixed. Any
objections?

No objections -> priority lowered.

*** Issue 50972 has been marked as a duplicate of this issue. ***

There is a new switch
-J-Dnetbeans.javacore.background_scanning=true
which forces IDE to do scanning on background.
This switch is experimental (not official) and bugs related to this
switch can be closed as WONTFIX (for now). Anyway we appreciate your
feedback (preferably add your experiences and opinions as a comments
to issue 43909).

Known issues: code completion, code folds and all stuff requiring java
model access are postponed till scanning is finished.

Navigator postponed as well.

As I noted previously, we did fix the unnecessary scanning of build products.
The remaining things that are being scanned during build are external binaries
if they are unscrambled - the things that the IDE does not have sources for.
This cannot be avoided, so I am closing this as FIXED as a whole (since we fixed
the part that could be fixed - the remaining part cannot be fixed).

Reorganization of java component