Build Monitor: per-builder events and example view

[vogella]

CI verification PR. Adds PRE_PROJECT_BUILD / POST_PROJECT_BUILD events to IResourceChangeEvent, fired per builder from BuildManager.basicBuild, and a new org.eclipse.ui.examples.buildmonitor example view that consumes them.

This branch is stacked on top of upstream PR eclipse-platform#2664 (Replace per-bit listener count fields with an AtomicIntegerArray on eclipse-platform/eclipse.platform). The array-based bookkeeping makes the new 64/128 bitmasks work without any change to ResourceChangeListenerList.

---

Fallback if upstream PR eclipse-platform#2664 is rejected

If the AtomicIntegerArray refactor is not merged, the per-builder events commit needs the following addition to ResourceChangeListenerList.java so that hasListenerFor(64) and hasListenerFor(128) actually return true for registered listeners (otherwise both new events are silently dropped):

@@ -60,6 +61,8 @@ public class ResourceChangeListenerList {
 	private volatile int count8 = 0;
 	private volatile int count16 = 0;
 	private volatile int count32 = 0;
+	private volatile int count64 = 0;
+	private volatile int count128 = 0;

@@ -114,6 +117,12 @@ public class ResourceChangeListenerList {
 		if ((mask & 32) != 0) {
 			count32++;
 		}
+		if ((mask & 64) != 0) {
+			count64++;
+		}
+		if ((mask & 128) != 0) {
+			count128++;
+		}
 	}

@@ -138,6 +147,10 @@ public class ResourceChangeListenerList {
 			return count16 > 0;
 		case 32:
 			return count32 > 0;
+		case 64:
+			return count64 > 0;
+		case 128:
+			return count128 > 0;
 		default:
 			return false;
 		}

@@ -170,6 +183,8 @@ public class ResourceChangeListenerList {
 		count8 = 0;
 		count16 = 0;
 		count32 = 0;
+		count64 = 0;
+		count128 = 0;
 	}

@@ -191,6 +206,12 @@ public class ResourceChangeListenerList {
 		if ((mask & 32) != 0) {
 			count32--;
 		}
+		if ((mask & 64) != 0) {
+			count64--;
+		}
+		if ((mask & 128) != 0) {
+			count128--;
+		}
 	}

Recovery flow in that case: git rebase --onto origin/master aa8786ac75 to drop the refactor commit, then apply the diff above to the per-builder events commit via git commit --amend.

[gemini-code-assist]

Code Review

This pull request introduces per-builder build events (PRE_PROJECT_BUILD and POST_PROJECT_BUILD) to the Eclipse Resources framework, enabling more granular monitoring of the build process. The implementation includes updates to the event notification system, a new 'Build Monitor' example plugin, and comprehensive unit tests. Review feedback identified a potential violation of the IResourceChangeEvent contract regarding the timing of the POST_PROJECT_BUILD event relative to the workspace lock. Additionally, improvements were suggested for the example plugin to safely handle widget disposal during asynchronous UI refreshes and to ensure that exceptions from listeners are logged rather than silently ignored.

[gemini-code-assist]

The POST_PROJECT_BUILD event is currently fired before the workspace lock is re-acquired (via endUnprotected). This violates the general contract of IResourceChangeEvent which states that the workspace is closed for changes during notification. Since PRE_PROJECT_BUILD is fired with the lock held, POST_PROJECT_BUILD should ideally also be fired after endUnprotected to ensure consistency and that listeners see a locked workspace, unless the concurrent delivery while the lock is released is explicitly intended for performance reasons.

[gemini-code-assist]

The refreshAsync method should safely handle cases where the view or its control might be disposed. Accessing viewer.getControl().getDisplay() on a disposed widget will throw an SWTException. Although the listener is removed in dispose(), events already in the queue or concurrent notifications could still trigger this.

	private void refreshAsync() {
		if (viewer == null || viewer.getControl() == null || viewer.getControl().isDisposed()) {
			return;
		}
		Display display = viewer.getControl().getDisplay();
		if (display.isDisposed()) {
			return;
		}
		display.asyncExec(() -> {
			if (viewer != null && viewer.getControl() != null && !viewer.getControl().isDisposed()) {
				viewer.refresh();
			}
		});
	}

[gemini-code-assist]

It is generally better to log exceptions from listeners rather than silently ignoring them, even in an example plugin. This helps in diagnosing issues with custom listeners.

			} catch (RuntimeException e) {
				// a broken listener must not poison the notification
				e.printStackTrace();
			}

[gemini-code-assist]

Code Review

This pull request introduces per-builder build events, specifically PRE_PROJECT_BUILD and POST_PROJECT_BUILD, to the Eclipse core resources framework. These events enable granular tracking of individual builders within a project build cycle, supported by updates to the event notification system and a new 'Build Monitor' example plugin. A potential NullPointerException was identified in BuildManager.java where builder.getCommand() might return null, and a defensive check was suggested to prevent build interruptions.

[gemini-code-assist]

Potential NullPointerException if builder.getCommand() returns null. According to the IncrementalProjectBuilder#getCommand() documentation, the returned value may be null if the builder was not created from a build command. A defensive check should be added before accessing the builder name to ensure the build process is not interrupted by an unexpected NPE.

Suggested change

	IProject builderProject = builder.getProject();
	String builderName = builder.getCommand().getBuilderName();
	workspace.broadcastProjectBuildEvent(builderProject, builderName,
	IResourceChangeEvent.PRE_PROJECT_BUILD, trigger);
	IProject builderProject = builder.getProject();
	String builderName = builder.getCommand() != null ? builder.getCommand().getBuilderName() : null;
	workspace.broadcastProjectBuildEvent(builderProject, builderName,
	IResourceChangeEvent.PRE_PROJECT_BUILD, trigger);

[gemini-code-assist]

Code Review

This pull request introduces per-builder build events (PRE_PROJECT_BUILD and POST_PROJECT_BUILD) to the Eclipse core resources framework, allowing listeners to track individual builder execution within a project build. The changes span the event notification system, workspace management, and include a new 'Build Monitor' example plugin along with unit tests. Feedback highlights a potential NullPointerException risk when accessing builder commands, suggests simplifying array reversal logic using standard library methods, and recommends using a fixed locale for formatting technical timing data to ensure consistency across environments.

[gemini-code-assist]

While builder.getCommand() is generally expected to be non-null during a build, it is safer to perform a null check before accessing getBuilderName() to prevent a potential NullPointerException in edge cases where a builder might not be correctly initialized or associated with a command.

[gemini-code-assist]

The manual array reversal in getElements is functional but can be simplified using Collections.reverse() on a list view of the array. This improves readability and leverages standard library utilities.

Object[] arr = sessions.toArray();
Collections.reverse(Arrays.asList(arr));
return arr;

[gemini-code-assist]

The formatMillis method uses String.format with the default locale. While usually acceptable for UI, technical timing data often benefits from a consistent format (e.g., using Locale.ROOT) to avoid variations in decimal separators (comma vs. dot) across different system locales.