The JTable Class in JFC 1.1

By Philip Milne

By stripping away what wasn't needed and holding on to the rest, the  Swing team has come up with a lean, mean JTable class that makes it easy  to create, manage, and optimize tables using Swing.

Much of the streamlining of the JTable class took place during the final  stages of the development of Swing, and we found that we had to add quite  a few features and capabilities that were not backwards-compatible with  previous early-access versions of the JTable class.

Consequently, developers who have written JTable code using early-access  versions of Swing will probably have to do some revising when they start  migrating their JTable code to the latest version of Swing.

This article provides  some tips on handling challenges you may encounter when you start developing  programs using the turbocharged version of the JTable class that made  its debut in Version 1.0 of Swing.

Most of these tips are presented in the form of text files that have  not yet been fashioned into Web pages.

Later in this article, you'll find links to these accompanying text files.  A number of the topics covered in these files will be addressed in greater  detail in future issues of The Swing Connection. Meanwhile, though, the  information they contain is so important that we have provided them here  in their original form.

Apart from one rather sweeping change -- specifically, a formal separation  of the JTable class and the DefaultTableModel -- the JTable modifications  in Version 0.7 for the most part are syntactic. There have been no changes  to the fundamental architecture, which seems during the development of  Swing to have worked well in most situations. But we have made a number  of internal changes that will let the various parts of the table package  communicate more directly with one another, resulting in better performance.

With this release, all significant bottlenecks that had reduced JTable's  efficiency in working with large tables appear to have been been removed,  and JTable's operations have been streamlined so extensively that very  little processing time is spent inside the JTable machinery during rendering.

And improvements keep coming: The next phase of JTable optimization will  usher in some specialized renderers that should make scrolling through  large tables of simple types much faster.

When all these changes are complete, we believe the result will  be a table component that can serve both as a practical and efficient  front end for database-like applications and as a framework for creating  much more elaborate interfaces using the many customizable parts of the  JTable's design.

We decided to perform surgery on the JTable API after feedback from developers  revealed several areas that appeared to be causing problems. The text  files provided with this article describe the modifications that were  made in the JTable class as a result of this developer feedback. Included  too is a porting guide that provides tips on modifying existing code to  work with the newly rewritten JTable API.

In covering these topics, the text files supplied with this article (listed  in the next section, "Links to the text files")  address the following issues:

• What mechanism is used to identify columns? This area of  inquiry distilled down to just one question: Should cells in tables  be accessed using integers or identifiers?
   
• In what order should rows and columns be accessed? In other  words, row first or column first? In previous versions of Swing, the  order of row and column access was inconsistent: Some methods took arguments  that expected a row designator to come first, while others expected  a column to be their first argument.
   
• What kinds of sorting methods should be used in the JTable API? Some developers told us they often needed to see many different views  of a single table model and sometimes wanted each view to show the data  in a different order. So they felt that views, not models, had to be  responsible for the sorting. Other JTable users pointed out that models  often had special knowledge of the data they handled, and therefore  could sort much more efficiently. Proponents of this view often add  that sorting is a data issue, not a UI issue, and declare that for this  version it belongs in the model.
   
• Should JTable be closely associated with a default table model? In previous versions of Swing, the JTable class was closely associated  with a default table model. Generally, though, it is much better to  wrap data in an application with the methods from the TableModel interface  than to copy it into the DefaultTableModel. Consequently, DefaultTableModel  is de-emphasized in Version 0.7 of Swing.

The text files provided with this article explain exactly what the Swing  team did to improve JTable in Version 0.7 of Swing, and exactly why everything  was done the way it was.

If you would like to know how to modify your code to work with the new  JTable API -- but aren't interested in all the details of the changes  made and why -- you can navigate straight to the Porting.txt file, which supplies some tips on updating existing code to work with  the new API. If you're interested in the nitty-gritty, you might want  to browse some of the other text files. Here's what those files contain:

• README.txt: Covers the same topics  discussed in this article, but in more detail.
   
• Warning.txt: A warning message  originally issued with the Swing 0.6 release in JDK 1.2. (Unfortunately,  Version 0.6.1 of Swing was released prior to JDK 1.2.)
   
• FlawsInV5.txt: Explains how  certain problems in Swing 0.5 helped us determine what solutions  to offer in the new API.
   
• Sorting.txt: Attempts to answer  to the question, Where does sorting belong?
   
• IdsVersusInts.txt: Addresses  the question, Should cells be accessed using integers or identifiers?
   
• ArgumentOrdering.txt:  Asks the question: Which way around should cell access arguments be?
   
• Porting.txt: Provides suggestions  for porting what are now legacy JTable programs to the new JTable API.
   
• APIChanges.txt: Lists all the  JTable methods that were changed between Versions 0.5/0.6 and Version  0.6.1 of Swing.

The decision to make sweeping changes in the JTable API at this late  stage was not taken lightly. One factor that helped persuade Swing's designers  to forge ahead was the concern that the functionalities of the JTable  class were beginning to expand the JTable class into a class that resembled  a spreadsheet or data-repository mechanism, which is not what JTable was  intended to be.

In Version 0.7, the Swing team decided to settle on a clear definition of JTable's primary function -- specifically, to provide an editable view  of tabular data -- and to draw a clear boundary around JTable to ensure  that there would be no further attempts to provide any other other kinds  of table functionalities from inside the Swing code base. By abandoning  all attempts to find JTable solutions to the kinds of problems that JTable  was not suited for, Swing's creators felt that they would be able to focus  more intently on improving the efficiency and quality of the JTable as  a UI component whose primary task is to provide an editable view of tabular data.