Where does sorting behavior belong?

A. "I may want to see many different views of a single table
model and I might want each view to show the data in a different
order, clearly the view has to be responsible for the sorting".

B. "The model may have special knowledge of the data which enables it
to sort much more efficiently. Anyway, sorting is a data issue not a
UI issue, it belongs in the model".

A. "If sorting belongs in the model, all of the TableModels that are
written will need to code a sorting algorithm. Since a reasonable job
can be done generically, why not do it once in the view?".

B. "What about filtering: showing rows of data only if they meet
certain criteria? That can be done generically too so it too should go
in the UI. Now your UI is becoming a database."

Etc.

One solution is to implement sorting in a DefaultTableModel (as was
implemented in the last release) and allow people to add their
specialized sorting needs by subclassing a "compare"
method. Alternatively, we could do a sorting interface (like JGL)
which separates the data from the algorithm.  But then should we do a
filtering interface too? And what about derived columns? Will people
have to wait for release 4.17 to have a column of totals?

From these discussions one thing seems clear, if we respond to every
reasonable request about what the JTable could do generically it is in
danger of assuming the responsibilities of a full blown spreadsheet. 

A solution

One approach is to borrow a solution from the OS world: pipes. By
making the TableModel interface self describing it is possible to
implement a sorting algorithm as "virtual table" that implements the
model interface with respect to any other table model. The sorting
object does not copy the data from the model; it simply redirects
queries about it through an internal array of integers which hold the
its current state: the order of the rows.

We have decided to use this approach and to remove the sorting code
from the JTable altogether. This means the sorting behavior is not
owned by the view but still allows a single generic table sorter to
be attached to any model. An example TableSorter is included in the
Swing examples area but this can easily be replaced with other commercial
sorting libraries or proprietary algorithms that exploit special
knowledge of the data, either to improve performance or customize the
behavior for a particular application.

More advanced features like filtering, or even simple calculation
engines can use the same technique and will not require any extra APIs
from Swing.

Perhaps most importantly, when the JTable is being used in the
simplest situation, to show ten rows of three columns without the need of
any of the features above - the API and application infrastructure 
are not cluttered with the features which are not needed.

The piping strategy may not suit every situation and it is not
enforced by the new APIs; it is still just as easy to layer
all of the features above directly into a model when this is the
method of choice.