Refactoring JOptionPane to allow easier customization

Name: gm110360 Date: 04/19/2002


FULL PRODUCT VERSION :
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build
1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)

FULL OPERATING SYSTEM VERSION : Microsoft Windows 2000
[Version 5.00.2195]




A DESCRIPTION OF THE PROBLEM :
JOptionPane needs to be more modularized so that it can be
extended and enhanced---specifically, it needs a
JOptionPane factory method. An example enhancement (itself
an issue) is adding verify-before-closing functionality,
for which the Java Tutorial recommends adding a window
listener to the dialog in which a JOptionPane is used.

It would be preferable to simply subclass JOptionPane so
that CustomOptionPane.showConfirmDialog() would use the
correct type of dialog that would add verify-before-closing
support. All showConfirmDialog() variations eventually call
showOptionDialog(), which then calls the createDialog()
method. It should be simple, then, to override createDialog
(), modify the created dialog, and then return it. Adding
verify-before-closing support would then be as simple as
subclassing JOptionPane and modifying the dialog returned
from createDialog().

The problem is that showOptionDialog() does not call
createDialog() on the current JOptionPane() (the previous
methods are, after all, static), but on a *new* created
JOptionPane which wraps whatever component is being used
for display. The actual JOptionPane creation must therefore
be replaced with a CustomOptionPane creation, but "new
JOptionPane(..." occurs four times and means that
showInputDialog(), showOptionDialog(),
showInternalOptionDialog(), and showInternalInputDialog()
will all have to be replaced, duplicating original
JOptionPanel code and changing one line in each to "new
CustomOptionPane(...".

This could easily be rectified by replacing each "new
JOptionPane(..." call to "createOptionPane(...". That way,
a custom verify-before-closing option pane dialog could
easily be created using the following steps:

1. Subclass JOptionPane and override createDialog() to
modify the returned dialog currectly (adding the
appropriate listeners).

2. Override createOptionPane() to return an instance of
CustomOptionPane rather than JOptionPane.

As it is now, not only does #1 have to take place, all of
the static functions must be wholly cut and pasted into the
new class and a single line in each changed to create the
correct type of JOptionPane subclass.

This bug can be reproduced always.
(Review ID: 137831)
======================================================================