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.
This bug was originally marked as duplicate of bug 194810, that is already resolved. This bug is still valid, so this seems to be another bug, but it might be related. Build: NetBeans IDE 7.3 Beta (Build 201210011125) VM: Java HotSpot(TM) Client VM, 23.5-b02, Java(TM) SE Runtime Environment, 1.7.0_09-b05 OS: Windows 7 User Comments: GUEST: Trying to run simple java class with main, the background scanning blocks it and message appears saying "Classpath scanning, wait please" or something... GUEST: Cancelled background task scanning projects GUEST: It's always doing a background scanning then a popup appears telling me the IDE has been unresponsive. Stacktrace: java.lang.Exception: Scan canceled. at java.lang.Thread.getStackTrace(Thread.java:0) at org.netbeans.modules.parsing.impl.indexing.LogContext.create(LogContext.java:113) at org.netbeans.modules.parsing.impl.indexing.LogContext.create(LogContext.java:106) at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.stateChanged(RepositoryUpdater.java:579) at org.openide.util.ChangeSupport.fireChange(ChangeSupport.java:133) at org.openide.util.ChangeSupport.fireChange(ChangeSupport.java:119)
Created attachment 126464 [details] stacktrace
621628: Scan after svn move - legal. 617648 & 615018 & 612078 & 568834: VcsVisibilityQueryImplementation changes the file visibility, newly visible fiels needs to be rescanned. The events from VcsVisibilityQueryImplementation are questionable as they are global and affect whole IDE. All the roots need to be rechecked for up to date (time stamp checking). Please evaluate if they are needed. Shouldn't they affect just single root? If so the VisibilityQuery API should be extended to provide the changed root (removes a need to time stamp check the unaffected roots).
> Shouldn't they affect just single root? > If so the VisibilityQuery API should be extended to > provide the changed root (removes a need to time stamp check the unaffected > roots). yes, VCS knows which files are affected by the visibility change and could (if provided by VQ) notify only the affected files or their common roots
The simple api change appears to be to create a subclass of ChangeEvent that would list the FileObjects affected and be passed to ChangeListeners listening on VisibilityQuery. Ok for everyone?
OK for me.
Created attachment 126914 [details] api patch
please review this small api change to communicate between vcs and java subsystems.
The patch is OK for me (java, parsing).
Integrated into 'main-golden', will be available in build *201211030001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/f009a4981039 User: Milos Kleint <mkleint@netbeans.org> Log: #220749 stop using ChangeSupport we will need to pass custom ChangeEvent subclass in some cases
How many listeners would be added to this List? If it's more than a couple, or the list will be very volatile, then "synchronized" should not be used to manage this list. A ConcurrentHashMap<K,K> would be a better choice, because then no one will be blocked. This is very important for a volatile list. In order traversal doesn't appear to be a problem, and the iterator for CHM will also not hold off access to the list of listeners. If notifications need to be ordered, then they should go into a Queue which can then be fed to a single thread traversing the list and doing the notifications. That complicates the design of the class more, from a logic perspective, but will make it much more performant, and help with easing the "delays" users see when interacting with VCS.
http://hg.netbeans.org/core-main/rev/44c501387c00 reassigning to vcs to implement the changeevent subclass
fixed in core-main #e6efd2712c53
(In reply to comment #12) > fixed in core-main #e6efd2712c53 for partially for cases when the IDE explicitly queries a files visibility one more fix will follow for cases when vsc fires because of a status change. see also issue #221831
Integrated into 'main-golden', will be available in build *201211100001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/44c501387c00 User: Milos Kleint <mkleint@netbeans.org> Log: #220749 api adding a ChangeEvent subclass carrying more information about VisibilityQuery changes
Integrated into 'main-golden', will be available in build *201211110001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/e6efd2712c53 User: Tomas Stupka <tstupka@netbeans.org> Log: in case particular files are know then also fire visibility change providing list of those files Issue #220749 - Background Scanning
FYI: I can see a sigtest report from Nov 10: > email: api-changes@netbeans.org > SignatureTest report > Base version: 1.32 > Tested version: 1.32 > Check mode: src [throws normalized] > Constant checking: on > > > Added Classes > ------------- > > org.netbeans.spi.queries.VisibilityQueryChangeEvent E.g. no version change (1.32 -> 1.32) and an API change. Such API changeset should not be allowed to propagate to main-silver. But probably it is some merge issue, as I can see that 44c501387c00 properly changed version from 1.31 to 1.32... who knows, the log files from push-core-main are already gone.
> (In reply to comment #12) > fix will follow for cases when vsc fires because of a status change. see also issue #221831 fixed in core-main #6caef408346c and core-main #5637f846d4e7