Merge branch 'main' of github.com:andrewcmyers/oodds

lectures/concurrency/index.html

@@ -173,7 +173,7 @@ <h3>Priorities and preemption</h3>
 
 <h3>Daemon and normal threads</h3>
 <p>
-A thread is either a <em>daemon</em> or a <em>normal</em> thread.
+A thread is either a <strong>daemon</strong> or a <strong>normal</strong> thread.
 Daemon threads are used for minor or ephemeral tasks such as timers or sounds.
 The initial thread (the one that runs <code>main</code>) is normal.
 The application halts when either <code>System.exit(...)</code> is called or all
@@ -265,7 +265,7 @@ <h2>Race conditions</h2>
 be interrupted by another thread. This does not mean that when one thread
 executes, say, <code>withdraw()</code>, that all other threads are suspended.
 However, it does mean that as far as the programmer is concerned, the system
-<em>acts</em> as if this were true.
+<strong>acts</strong> as if this were true.
 </p>
 
 <h2>Critical sections and atomicity</h2>
@@ -346,11 +346,11 @@ <h2>Mutexes and <code>synchronized</code></h2>
 <p>
 A <b>lock</b> is a special object that can be <b>held</b> by threads, with some
 restriction on which threads can hold it. The simplest form of lock is a
-<b>mutual exclusion locks</b>, or <b>mutex</b>, which can be held by at
+<b>mutual exclusion lock</b>, or <b>mutex</b>, which can be held by at
 most one thread at a time.
 </p>
 <p>
-Threads can <em>acquire</em> them and <em>release</em> mutexes.
+Threads can <strong>acquire</strong> them and <strong>release</strong> mutexes.
 </p>
 <p>
 <b>acquire</b>: When a thread tries to acquire a mutex, it first checks whether
@@ -447,17 +447,17 @@ <h3>Mutex syntactic sugar</h3>
 <h3>Mutex variations</h3>
 
 <p>
-Java mutexes are <em>reentrant mutexes</em>, meaning that it is harmless for a
+Java mutexes are <strong>reentrant mutexes</strong>, meaning that it is harmless for a
 single thread to acquire the same mutex more than once. One consequence is that
 one synchronized method can call another on the same object without getting
 stuck trying to acquire the same mutex. Each mutex keeps track of the number of
 times the thread has acquired the mutex, and the mutex is only really released
 once it has been released by the holding thread the same number of times.
 </p>
 <p>
-A locking mechanism closely related to the mutex is the <em>semaphore</em>,
+A locking mechanism closely related to the mutex is the <strong>semaphore</strong>,
 named after <a href="https://en.wikipedia.org/wiki/Railway_semaphore_signal">railway
-semaphores</a>. A <em>binary semaphore</em> acts just like a (non-reentrant)
+semaphores</a>. A <strong>binary semaphore</strong> acts just like a (non-reentrant)
 mutex, except that a thread is not required to hold the semaphore in order to
 release it. In general, semaphores can be acquired by up to some fixed number
 of threads, and additional threads trying to acquire it block until some
@@ -503,7 +503,7 @@ <h2>When is synchronization needed?</h2>
 an inconsistent view of their contents.
 </p><p>
 Synchronization is also needed when we need to make sure that one
-thread <em>sees</em> the updates caused by another thread. It is possible
+thread <strong>sees</strong> the updates caused by another thread. It is possible
 for one thread to update an instance variable and another thread to later
 read the same instance variable and see the value it had before the update.
 This inconsistency arises because
@@ -528,7 +528,7 @@ <h2>When is synchronization needed?</h2>
 <p>
 What possible values of <code>y</code> might be printed by Thread 2? Naively, it
 looks like the only possible value is 1. But without synchronization, Thread 2 could
-observe the update to <code>x</code> <em>before</em> the update to <code>y</code>.
+observe the update to <code>x</code> <strong>before</strong> the update to <code>y</code>.
 The fact that Thread 1 assigned to <code>y</code> before
 it assigned 1 to <code>x</code> does not matter! This behavior can and does happen frequently
 with modern hardware. This bizarre state of affairs shows that programming with
@@ -548,7 +548,7 @@ <h2>When is synchronization needed?</h2>
 change at any time. Any invariant that involves the value of such a
 field cannot be relied upon.
 </p><p>
-Note that <em>immutable</em> state shared between threads doesn't need
+Note that <strong>immutable</strong> state shared between threads doesn't need
 to be locked because it cannot be updated. This fact
 encourages a style of programming that avoids mutable state.
 </p>

lectures/gui/index.html

@@ -1,4 +1,4 @@
-<h1>Graphical User Interfaces: Display and Layout</h1>
+<h1>Graphical User Interfaces</h1>
 <p>
 One of the driving forces behind the development of object-oriented programming
 was the need to create <strong>graphical user interfaces</strong> (GUIs). It is not surprising,
@@ -85,6 +85,7 @@ <h2>Node class hierarchy</h2>
         <li>GridPane
         <li>FlowPane
         <li>BorderPane
+        <li>AnchorPane
         </ul>
       <li>Chart
       <li>Axis
@@ -97,6 +98,10 @@ <h2>Node class hierarchy</h2>
   </ul>
 </ul>
 </tt>
+<p>
+Scene graphs show up in other settings. For example, video games
+are often built using 3D scene graphs.
+</p>
 <h2>Building a GUI</h2>
 <p>
 A scene graph must be constructed. This can be done either by either</p>
@@ -125,10 +130,12 @@ <h2>Building a GUI</h2>
 </p>
 <p>
 A scene graph can also be created in advance using the <a
-href="https://www.oracle.com/technetwork/java/javase/downloads/javafxscenebuilder-info-2157684.html">
-JavaFX SceneBuilder application</a>. SceneBuilder saves the scene in
-XML format in an <tt>.fxml</tt> file, which can be loaded by the application to
-create the entire scene graph at once.
+href="https://gluonhq.com/products/scene-builder/"> JavaFX Scene Builder
+application</a>. Scene Builder saves the scene in XML format in an
+<tt>.fxml</tt> file, which can be loaded by the application to create the
+entire scene graph at once. With this approach, the application code
+does not need to know about many details of the scene graph, such as
+intermediate nodes used only for layout.
 </p>
 <h2>Layout</h2>
 <p>
@@ -145,6 +152,8 @@ <h2>Layout</h2>
 children into a regular grid, like an HTML table. <code>FlowPane</code> lays out its children like
 words of text, in a series of top-to-bottom rows in which each row contains children laid out left-to-right. <code>BorderPane</code> expects to have five children; one is placed in the center and the four others
 are placed at the top, bottom, right, and left.
+<code>AnchorPane</code> places children relative to its sides, following
+to constraints attached to the children.
 </p>
 <div class=figure>
 <canvas id=panes style="width: 600px; height: 300px"></canvas>

lectures/guievents/button-action.fxml

@@ -0,0 +1 @@
+<Button id="pressme" fx:id="b" text="Press me!" onAction="#handleButtonPressed">

lectures/guievents/desugared_lambda.java

@@ -1,5 +1,5 @@
 b.setOnAction(new EventHandler<ActionEvent>() {
         void handle(ActionEvent e) {
-            print("button clicked");
+            println("button clicked");
         }
     });

lectures/guievents/desugared_top_level_class.java

@@ -1,6 +1,6 @@
 class ButtonClicker implements EventHandler<ActionEvent> {
     void handle(ActionEvent e) {
-        print("button clicked");
+        println("button clicked");
     }
 };
 ...

lectures/guievents/fxmlMain.java

@@ -0,0 +1,23 @@
+public class Main extends Application implements Initializable {
+    @FXML private Button theButton;
+    @FXML private TextArea theTextArea;
+
+    public static void main(final String[] args) {
+        Application.launch(args);
+    }
+
+    @Override public void start(final Stage stage) {
+        try {
+            final URL r = getClass().getResource("simple.fxml");
+            final Parent node = FXMLLoader.load(r);
+            final Scene scene = new Scene(node);
+            stage.setTitle("FXML demo");
+            stage.setScene(scene);
+            stage.sizeToScene();
+            stage.show();
+        } catch (final NullPointerException|IOException e) {
+            System.out.println("Can't load FXML file.");
+            try { stop(); } catch (final Exception e2) {}
+        }
+    }
+}

lectures/guievents/handleButtonPressed.java

@@ -0,0 +1,4 @@
+@FXML
+private void handleButtonPressed(final ActionEvent e) {
+    println("button clicked");
+}