Scaffold small client application
Slacker Guide to Java Swing Application Development
Using the Scaffold small client application framework


The Slacker Guide provides tutorials of example applications, presentation of core concepts, and details about the internal workings of the Scaffold small client application framework. It is assumed that the reader has general Java coding experience, at least basic knowledge of Swing, and is familiar with multithreaded programming, especially as it applies to Swing. The more you know, the better you will understand (and appreciate!) why and how the framework simplifies application development.

For those with extensive Swing experience or that prefer to learn by example, the Applications tutorial is probably the best place to start. Then, return here to discover the details.

Core Concepts

As mentioned on the home page, Scaffold is a framework that replaces complex coding of key application infrastructure with simple declarative programming in properties files. This essentially amounts to configuring an application versus coding one.


Fundamentally, any Scaffold application can be declared (configured) using a single properties file. Period. That is a key concept to remember.

Most applications will leverage multiple properties files for many of the same reasons code is generally split into multiple files - convenience, clarity, reuse, etc. Ultimately, though, all of those properties files are coallesced at runtime to compose an application definition that can be expressed as a single properties file. Similar to Java coding, Scaffold properties can be refactored and reorganized to suit evolving needs.


Scaffold application declaration uses standard Java properties files with a twist. Scaffold properties files are layered. Layering simply means that each Scaffold properties file is retreived as the logical merging of all instances of that file. For example, if the file myapp/ exists in two locations on the Java classpath, say myapp1.jar and myapp2.jar, the resulting properties loaded by Scaffold will be the equivalent of loading the file first in the classpath, say from myapp1.jar, and then adding or overriding any properties from the file second in the classpath. This is in contrast to standard Java properties loading which reads properties in only one file from the foremost location in the Java classpath.

Layers enable Scaffold applications to be:

  • OS aware; e.g. menus, icons and mnemonics can be easily made appropriate for Mac OS X, Linux and Windows
  • "skinned" (e.g. Swing applications) without having to touch the core application files; a very convenient feature for branded or user tweakable applications
  • extended or overridden, similar to subclassing Java classes
  • easily patched or upgraded

To make layers even more powerful, Scaffold application declaration adds a += operator. This operator is used to combine properties defined in multiple layered properties files. For example, if myapp/ in myapp1.jar has a line of text:

   aprop = foo

and, in myapp2.jar myapp/ has this line:

   aprop+= bar

then, Scaffold would load the text "foobar" (i.e. the concatenation of "foo" and "bar") for the property aprop.

It doesn't seem like much here, but the immense value of layers and the += operator is readily apparent in actual applications.


In a way, Scaffold is perhaps a platform as much as a framework; where, a platform is a fully functional foundation that does something useful, and a framework is just implementation of core capability that can be aggregated and extended to do something useful. If Scaffold is a platform, then it is intended to be a very lightweight one - emphasis on the small in "small client application framework". Scaffold avoids a heavy handed approach, and tries hard to integrate external Java classes without need of modification.

As a platform, Scaffold provides select core pieces of functionality common to typical client applications.

Application Life-Cycle

Scaffold defines a simple application life cycle:

  • Instantiate - create a new application instance
  • Initialize - initialize the application; e.g. create a GUI and initialize values
  • Open - open an item in an application instance
  • Close - close an application instance

Application Instance Management

Each Scaffold application can specify (in the application properties file) whether only one instance or multiple instances are allowed to run at a given time.

The default is single instance, in which case any calls to open an item in that application results in the item being opened in the existing instance (or an instance being created if one is not already open). If an attempt is made to launch the application a second time, the Scaffold framework in the second JVM will quickly hand any items to open to the existing instance and exit the second JVM. Most of the example applications use the default single instance mode - try running a second instance concurrently, and see what happens!

In the case of multiple instances, each application can further specify whether each instance runs in a separate JVM, or inside a single shared JVM. Running inside a shared JVM has the advantage of not incurring the memory and startup overhead of a new JVM, and applications inside a shared JVM can efficiently pass Java objects to other application instances. Furthermore, when using a single shared JVM, an application can specify whether opening the same item twice results in opening a new application instance, or in reopening an existing instance. For example, in the latter case, a Swing application might be brought to the foreground.

Application Suites

Multiple applications can be organized into a suite. Each application in the suite can specify whether it uses the single or multiple instance model, but all application instances in the suite will be opened in a single JVM. This can be very handy in an enterprise setting, for example, where multiple applications are integrated to perform related tasks.

Default Application

Scaffold provides a default application implementation that can be used as-is for many typical applications; there is no need to create a Java subclass. Often, the only Java code an application developer needs to write is for custom business logic.


Scaffold applications are composed of two primary entities: Application Element and Invoker, which are connected and managed by the ApplicationContext. Scaffold application properties files define Application Element and Invoker objects, and how they are connected.


The ApplicationContext is the heart of every Scaffold application. Each instance of an application has its own ApplicationContext. The ApplicationContext is the central administrator - it manages all of the Application Elements, and Application Elements notify the ApplicationContext of significant changes in application state, and the ApplicationContext in turn forwards those changes to other interested Application Elements. ApplicationContext change notification is performed synchronously (i.e. in the thread initiating the notification), but can be made asynchronous or made to perform in the Event Dispatch Thread by using an Invoker.

Generally, Application Elements instigate change notifications, and Invokers that listen for those changes respond by performing a task - often, invoking a method on another Application Element.

Application Element

An Application Element is simply an object managed by the ApplicationContext. Generally, each Application Element specifies the class name for an instance of that element, or a class that serves as a factory to create an instance. In addition, parameters to configure that object are specified as well.

Application Elements are not required to implement any particular interface or extend special classes. However, for tight integration, Application Elements can use one of several means to obtain a reference to the ApplicationContext or configuration of the Application Element.


An Invoker is a special type of Application Element that performs a task, usually in response to a change in the ApplicationContext. The default Scaffold Invoker class knows how to forward changes in the ApplicationContext to Application Elements, and can do this in synchronous or asynchronous modes, including logic to automatically use the Event Dispatch Thread when the notified Application Element is an AWT or Swing object.

Invokers can be thought of as a more generalized and enhanced form of the SwingWorker.

Invokers are required to implement a Scaffold interface, but it is generally not necessary to create a custom Invoker, as the default Invoker in Scaffold is usually robust enough to handle the role.

© 2007 Meldcraft Corporation