GeoTools : Swing module branch

What's going on

The swing module, which contains a small collection of GeoTools GUI components, is being rewritten. The work is happening on the swing-refactor branch which will be merged back into trunk to become part of the GeoTools 2.7 series.

The wish list for the work is:

  • Improve performance of the components, particular JMapPane and associated map display classes.
  • Introduce interfaces to make it easier for users to write their own custom components.
  • Separate display and controller functions in the various classes using model-view-presenter and humble dialog box approaches.
  • Greatly improve the unit test coverage.
  • Address a number of long-standing user requests for JMapPane including better resizing behaviour, drawing to screen while rendering and displaying rotated features.
  • (and the big one...) Promote the swing module to supported status.

Design and implementation


JMapPane is now written against the MapPane interface. Most of the logic for calculating display scale and handling zooming, panning etc has been separated out into a new JMapPaneController class, implementing a MapPaneController interface. This has allowed good unit test coverage of the display logic methods. Splitting the code into these separate classes has also made a lot cleaner and easier to follow.

JMapPane now supports rotated display as in this example with the countries shapefile...

The annoying resizing behaviour of the last version has been fixed so that the display scale remains constant when the pane is resized.


This class manages rendering tasks on a background thread for JMapPane. In the previous version of the swing module RenderingExecutor provided a single-thread, non-queuing service, ie. when a task was submitted any further tasks would be rejected until the first task completed (or was cancelled).

In the new module RenderingExecutor is an interface with a default RenderingExecutorImpl class provided. The new class offers more flexibility and better performance:

  • It provides a cached thread pool allowing a single executor to be shared between map panes.
  • Rendering update events are now published to listeners. These and all other events are published on a separate thread to that being used by the renderer.
  • The status of rendering tasks can be queried generally, by map pane or individually using a ticket class (RenderingTicket) which is issued when a task is submitted to the executor. The ticket class is also used when publishing task status events to listeners.
  • Unit test coverage is about 90%.