Order of indexes in table access methods

The issue of whether the methods in the API should be of the
form:

	getValueAt(row, column)

or

	getValueAt(column, row)

is something we had to find a consistent solution for as we didn't
feel we could leave the API with the methods defined both ways around.
(In the last release the TableModel, AbstractTableModel and
DefaultTableModel used the first convention and the JTable used the
second). As far as we can tell the developer community is fairly
evenly split on this emotive issue and whatever choice we make is going
to be unpopular with some.

Here are the issues we thought were important in deciding this:

Minimize the changes for people familiar with the conventions of other
environments

To the best of our knowledge, the majority of other Grids use a (row,
column) scheme.  One notable exception was NeXT's TableView object
which put the column (identifier) first. NeXT's UI kit was written in
Objective-C however, whose SmallTalk-like syntax allowed arguments to
be explicitly labeled and therefore imposed different (probably
better) constraints on the ordering of arguments.

Make the API consistent in a way that will require the fewest changes 
from people who already have tables working. 

Since most user code that has been written for the JTable has involved the 
creation of a TableModel this is the part that would be most disruptive to 
change. 

Copy the conventions in Mathematics

Someone wrote to us suggesting that the latter mechanism would be
consistent with the conventions used in Mathematics. Cartesian
geometry does use these conventions and most APIs that do graphical
plotting routines might trace their (x, y) conventions to their
Mathematical roots.

Tables, however, have a finite number of rows and columns, locate
their cells with integer indices and display their origin in the top
left of their view - for these the Matrix is probably a better
analogue and here Mathematical conventions are the other way around.

Conclusion

All in all it seemed that the (row, column) was what we should go for
and that the API should be changed throughout to make sure that all
methods that involved row and column indices would have the row index
first.