JTable: Time to Rethink NIH?

You know what Not Invented Here (NIH) means, Google it if you need help. I’m here to talk about one case where we may need more innovation: Swing’s JTable component.

Background

I really like JTable. JTable is a remarkably powerful GUI component, accommodating a huge spectrum of applications. Its design provides clear separation between the table, scroll pane, table header, cell renderers, cell editors, and the table model. The component is usable out of the box, and its modular design facilitates a great deal of customization. For instance, here is a screen shot from the RichJTable project:

You can find many other JTable extensions:

• JXTable
• TreeTables
• JIDE Grids
• JDataGrid

That’s just a quick search…there are many more out there.

Strong Specific, Weak General

All of these customizations — spreadsheets, tree tables, etc — extend JTable. The variety of custom components demonstrate just how flexible the original JTable design is. Is this a problem?

From page 164 of The Invisible Future: The Seamless Integration Of Technology Into Everyday Life:

In design, there is a trade-off between weak general and strong specific systems. Tools, like people, seem to be either a jack-of-all-trades, or specialized. Inherently “super-appliances” fall into the jack-of-all-trades weak-general category.

This weak general vs. strong specific trade-off plays a role in the design of all tools, including chisels, screwdrivers, bicycles and supercomputers. For reasons that we shall see, strong general systems have never been an option. One has always had to make a choice.

You can read Bill Buxton’s complete essay here. The point is, a Swiss Army Knife has a lot of tools, but they are all relatively weak. A dedicated spoon works a lot better than the weak spoon found on a Swiss Army Knife.

Lack of Outside Innovation

JTable is really good, but at its heart it is a weak-general tool. Writing a general-purpose table component is really hard, and the Swing team did a damn fine job with JTable. Thus, everybody else down the food chain (that I’m aware of) simply extends JTable.

JTable is good enough for 95% (?) of the use cases out there, but it is not as good as a dedicated spreadsheet. This is the problem. Grid components in dedicated spreadsheet applications are designed with one purpose in life: to display and edit spreadsheets. As such, they are strong-specific GUI components. In a dedicated spreadsheet, the GUI is crisp and responsive, focus traversal works, mouse clicks work, and data commits at the right time.

Many people have tried — including myself — to extend and coerce JTable into a spreadsheet component. But Swing JTable is subject to engineering tradeoffs like every other piece of software, and it can only be pushed so far. You can make JTable look and behave a lot like a good spreadsheet, but I doubt we will ever achieve perfection.

Consider IntelliJ IDEA, a product renowned for keyboard navigation. Unfortunately, keyboard navigation sucks whenever they use an editable JTable, such as in the Change Signature dialog:

Perhaps I need to embed a little video here to demonstrate the problems…basically, keyboard and mouse navigation just feel incredibly broken and wrong. JTable does the best that it can, but it is not a dedicated data entry component. JTable’s primary function is tabular data display, tabular data entry is a secondary feature for this general purpose GUI component.

A Radical Idea

I submit to you this idea:

Someone should write a dedicated Swing data entry grid component from the ground up, without extending JTable.

Random thoughts…

• This is a really hard project.
• This is a strong-specific component, designed for one purpose: data entry in a grid, like a spreadsheet.
• There are no constraints. You don’t have to support existing renderers, editors, or anything else.
• You should be able to achieve 100% fidelity with a dedicated spreadsheet component.
• Many businesses would *love* a data entry grid that *really works* flawlessly.

Anybody writing a data entry grid from scratch would certainly be accused of NIH. I can hear it now…”You are writing what??? You should just extend JTable! 95% of the functionality is already there!”

I believe that starting with a general-purpose component might make that final 5% impossible.

Conclusion

I hope I make it clear that this article is not a criticism of JTable at all. Pretending that a single GUI component can be perfect at *every* task is foolish and naive. Yet…I cannot say I have ever heard of someone writing a Java data entry grid — of Excel caliber — from scratch. Every single grid component I have seen extends JTable.

For most purposes, extending JTable is the right choice. But surely there are cases where a strong-specific, dedicated data entry grid component is more appropriate.

This entry was posted on Thursday, January 17th, 2008 at 9:39 pm and is filed under Java, Software Development. You can skip to the end and leave a response.