File Dialogs in Clojure

(See my full list of Clojure Swing examples and tutorials at Clojure Swing Interop)

When dealing with files, its very handy to use file dialogs. Here’s a quick example of using a JFileChooser  to select a file to slurp  and print.

Note the use of  (into-array [“txt”]) as an argument to the FileNameExtensionFilter constructor. This is because the file extensions are provided as a String...  meaning a java.lang.String  array.

Also note, the .showOpenDialog  call uses nil  instead of a JFrame . We do that because we don’t have a JFrame  showing that we want to associate the file dialog with.


Clojure JOptionPane

(See my full list of Clojure Swing examples and tutorials at Clojure Swing Interop)

Every complex GUI uses message dialogs. When using Clojure Swing interop, you will use the JOptionPane  for your message dialogs. Two keys to remember when using JOptionPane s, is that they should always be called from within the Event Dispatch Thread (EDT). Sometimes the JOptionPane  is shown by an ActionListener  that is already on the EDT, and sometimes you need to call invokeAndWait , because your current thread is not the EDT.

The other key point to remember with JOptionPane s is that you can associate the message dialog with a frame, or set the frame to nil . If a JOptionPane ‘s frame is set to nil , then the message dialog will center itself on the screen when it displays. If a JFrame  is provided to the JOptionPane , then the message dialog will center itself on the JFrame  it is associated with.

Here is a basic example that provides a button to click, and that displays a plain JOptionPane  with a message. The ActionListener  is called from the EDT, so the JOptionPane  is being called from the EDT.

Here is an example that shows a JOptionPane  that displays from a normal thread. The EDT must be explicitly called with invokeAndWait . The four most common types of message dialogs are shown.

Clojure Swing: Invoke Later

(See my full list of Clojure Swing examples and tutorials at Clojure Swing Interop)

When developing Swing GUIs for Clojure, understanding and using SwingUtilities/invokeLater  is crucial.

Event Dispatch Thread

Don’t confuse “thread” in this case with Clojure threading macros such as ->  and --> . Threading here refers to concurrency.

Swing GUI components are not safe to access concurrently. If two threads modify the same Swing component at the same time, the result is unpredictable. Java solved this problem by introducing the event dispatch thread. All modification Swing displays and component values should happen on the event dispatch thread.

There is only one event dispatch thread. You access it by creating a Java Runnable and passing it to SwingUtilities/invokeLater . Lucky for us, all Clojure functions are Java Runnables. Here’s the general format.


Remember, ALL the screen rendering and modifications to your Swing components happen on the event dispatch thread. That means, if you tie up the event dispatch thread doing something time consuming, your app will appear to hang. This creates a horrible user experience. Any runnables you create should complete quickly.

On a somewhat related note, any time a Swing component alerts you to an event or a value change, you will want to hand back that thread immediately and use a new thread to do any long tasks associated with the notifications.