Colin Gordon committed 9ca12a5

done, modulo cleaning up annotations after some checker fixes

Comments (0)

Files changed (4)


 		// TODO Auto-generated method stub
-	public Object execute(ExecutionEvent event) throws ExecutionException {
+	@UIEffect public Object execute(ExecutionEvent event) throws ExecutionException {
 		IWorkbenchPart part = HandlerUtil.getActivePart(event);
 		IObjectActionDelegate action = EditorPropertyTester.hasResourceSelection(part);
 		if (action == null) {


 	 * to stop at the next possbile exit point.
 	 * @param monitor
-	public void setMonitor(boolean monitorIn) {
+	@SafeEffect public void setMonitor(boolean monitorIn) {
 		if(monitorIn && !monitor) {
 			getStore().set(""); //$NON-NLS-1$
 			getTracker().set(""); //$NON-NLS-1$


-	public void finalize() {
-		fillMenu(); // Colin Gordon: BUG? This seems like an application bug for sure, even if it's not a ui threading bug
+	@SafeEffect public void finalize() {
+		fillMenu(); // Colin Gordon: BUG: finalizers run on their own thread!  Even if fillMenu() doesn't really need to be UI, this is at least bizarre
 	public void menuAboutToShow(IMenuManager manager) {
 +15 (3:00): 10.  Largely marking things like JFaceResources and (shockingly) SWT Font as mostly safe
 +15 (3:15): 8.  A UI type, and marking FieldEditor.setPropertyChangeListener as taking a @UI listener
 +5 (3:20): 4.  Marked OpenWith as a UI type (plus extra safeeffects to work around postDirectSupertypes()).
++15 (3:35): 3.  One remaining is de facto safe though that may not be the design.  Another is a potentially safe call from a finalizer (it's at least an application weirdness, but will never cause problems because Eclipse never unloads plugins and the finalizer is on a menu).  The last is sticking a UI property change listener into the global jface property store, which seems okay for this application because the only code that touches the property store in this program is in the UI.