Added comments in JUnitEventNotifier and MainJVM.java

ponderosaTX · ponderosaTX · commit 93db0ca4def6 · 2025-03-25T13:39:15.000-05:00
Changes to be committed:
	modified:   junit/JUnitEventNotifier.java
	modified:   repl/newjvm/MainJVM.java
diff --git a/drjava/src/edu/rice/cs/drjava/model/junit/JUnitEventNotifier.java b/drjava/src/edu/rice/cs/drjava/model/junit/JUnitEventNotifier.java
@@ -58,7 +58,13 @@
  * or removing listeners (writing) at a time, and no reads can occur
  * during a write.
  * <p>
- *
+ * Addendum [Corky March, 2025] In hindsight, the event notification framework is unnecessarily complex and buggy.  Essentially
+ * all event notification code runs in the "dispatch (event-handling) thread".  The design should have forced ALL event
+ * notication code to run in the dispatch thread.  Then the read-write locking protocol would be unnecessary.  I suspect
+ * that "adminstrative methods" like addListener and removeListener are accessed from outside of the dispatch thread.  In addition,
+ * some events are signalled by RMI calls from JUnitTestRunner (and elsewhere?) in the slave JVM.  The RMI "proxy" thead in 
+ * the main JVM apparently does not route event notifications through the dispatch thread. Ugh.
+ * <p>
  * <i>No</i> methods on this class should be synchronized using traditionalJava synchronization!
  * <p>
  *
diff --git a/drjava/src/edu/rice/cs/drjava/model/repl/newjvm/MainJVM.java b/drjava/src/edu/rice/cs/drjava/model/repl/newjvm/MainJVM.java
@@ -193,11 +193,11 @@ protected void handleSlaveWontStart(Exception e) {
     debug.log("Slave won't start", e);
     _state.value().startFailed(e);
   }
-    
-  
 
   /*
    * === MainJVMRemoteI methods ===
+   * [Corky March 2025] Should the notifications passed to the InteractionsModel and JUnitModel be delegated to the
+   * dispatch thread?
    */
   
   // TODO: export other objects, such as the interactionsModel, thus avoiding the need to delegate here?
