Community
Participate
Working Groups
When editing a role class the progress view sometimes shows many jobs relating to update of callin markers. When this happens the UI becomes less responsive. We should collate events as to reduce the number of update jobs.
Created attachment 172268 [details] implementation The patch fixes the immediate issue: - invalidate each role at most once - use 'baseMemberAdded' only if #members < 3 (per type) otherwise call invalidateBaseCU(..) regarding the enclosing compilation unit - when invoking invalidateBase(..) for the current editor input, trigger a full updateCallinMarkers(ResourceMarkable,..) Also included: - don't synchronize CallinMarkerRemover, saw a deadlock where multiple threads were processing JavaElementDelats. Deadlock is worse than markers removed at a wrong point in time. - make MethodMapping.findMethod(..) smarter so it finds callout-methods, too. (needed for callin/callout-markers at base-level callouts). - 'CallinMarkerCreator2.getAllMethodsAndFields(..)': find callout-methods, too Not working currently: - adding a method to a role-and-base does is not reflected in the deltas - arbitrary change in a role creates ADDED deltas for all method mappings
Patch has been committed as r519, r520.
(In reply to comment #1) > Not working currently: > - adding a method to a role-and-base does is not reflected in the deltas > - arbitrary change in a role creates ADDED deltas for all method mappings Following up on these in bug 317358.
With this patch markers in binary base class are not removed if a callin is removed. CallinMarkerCreator2.invalidateBase(IJavaElement) must also look for a CLASS_FILE parent.
Created attachment 172276 [details] Additional fixes (In reply to comment #4) > With this patch markers in binary base class are not removed if a callin is > removed. CallinMarkerCreator2.invalidateBase(IJavaElement) must also look > for a CLASS_FILE parent. Fixed by - symmetrically implementing invalidateBaseMarkable (was invalidateBaseCU) for Resources and JavaElements - implementing removal of JavaElement-based markers (as a FIXME actually) This solution is backed by the following cleanup: - use more explicit type IClassFile for element of JavaElementMarkable (we only use IResource or IClassFile as toplevel elements!)
Patch from comment 5 has been committed as r521.
Verified using build 201007050931.
