Huge JTables, nowadays...

Thread view:

Thomas G. Marshall - 11 Jan 2005 13:28 GMT

I have a fairly simple comment/question about the current state of affairs
in JTables, which have had a rather ugly beginning...

Back when things were rotten, actually a few rev's after when things were
truly rotten, when swing and JTables first came out, there was no facility
to easily create a huge JTable of, say, a million rows for example. IIRC,
there was a semi-limit of something like 50,000 rows---not sure on that.

UIW, this was because every single thing in the JTable by default needed be
(at first glance) right in memory, and they capped that to prevent the
operating system from doing the work of paging. Which is where the paging
really belongs if you ask me.

I had to design a cache system by hand, which is fairly simple and works.
In the realm of database design, of course, this sort of layer is more or
less common place, but I was building something without a true database, but
lifted out of a file, which is gross :) .

My question is: in the latest rev's of JTable, are there pre-cooked versions
of such things? Can JTables /easily/ handle near arbitrary numbers of rows?

Signature

"Well, ain't this place a geographical oddity!
Two weeks from everywhere!"

Reply to this Message

Filip Larsen - 11 Jan 2005 14:31 GMT

My question is: in the latest rev's of JTable, are there pre-cooked
versions

> of such things? Can JTables /easily/ handle near arbitrary numbers of rows?

JTable do in general not ask the TableModel for non-visible cell-values,
so your requirement translates almost directly to the implementation of
the TableModel. If you can make a TableModel that efficiently maps to
your data cache then you should have no trouble.

A simple example of a huge TableModel is:

import javax.swing.JFrame;
import javax.swing.JScrollPane;
import javax.swing.JTable;
import javax.swing.SwingUtilities;
import javax.swing.table.AbstractTableModel;

public class HugeTable extends JFrame implements Runnable {

public static void main(String[] args) {
SwingUtilities.invokeLater(new HugeTable());
}

class HugeTableModel extends AbstractTableModel {

public int getColumnCount() {
return 10;
}

public int getRowCount() {
return 10000000;
}

public Object getValueAt(int rowIndex, int columnIndex) {
return new Integer(rowIndex/(columnIndex+1));
}

}

HugeTable() {
getContentPane().add(new JScrollPane(new JTable(new
HugeTableModel())));
}

public void run() {
pack();
show();
}
}

Regards,

Signature

Filip Larsen

Reply to this Message

Thomas G. Marshall - 11 Jan 2005 16:06 GMT

Filip Larsen coughed up:

> My question is: in the latest rev's of JTable, are there pre-cooked
> versions
[quoted text clipped - 48 lines]
>
> Regards,

Yes, that was how I /expected/ it to work long ago, yet it still got
sluggish and then croaked at 50,000 lines or so (again, that number is very
approximate).

It sounds as if you're saying that the current JTable keeps no per-row
storage around, and merely asks the tablemodel for data as it needs to be
displayed, give or take some extra for algorithm hoo-hah, which seems ideal.

Are there any issues with such a huge (in pixel terms) JTable under control
of the JScrollPane? I understand that only what's visible is rendered, but
I'd be concerned about some default backing-store that might attempt
enormous pixelmaps.

Signature

Iamamanofconstantsorrow,I'veseentroubleallmydays.Ibidfarewelltoold
Kentucky,TheplacewhereIwasbornandraised.ForsixlongyearsI'vebeenin
trouble,NopleasureshereonearthIfound.ForinthisworldI'mboundtoramble,
Ihavenofriendstohelpmenow....MaybeyourfriendsthinkI'mjustastrangerMyface,
you'llneverseenomore.ButthereisonepromisethatisgivenI'llmeetyouonGod's
goldenshore.

Reply to this Message

Christian Kaufhold - 11 Jan 2005 16:54 GMT

[JTable will a lot of rows]

> It sounds as if you're saying that the current JTable keeps no per-row
> storage around, and merely asks the tablemodel for data as it needs to be
> displayed, give or take some extra for algorithm hoo-hah, which seems ideal.

If you use variable row heights, it uses one int per row, otherwise none.

> Are there any issues with such a huge (in pixel terms) JTable under control
> of the JScrollPane? I understand that only what's visible is rendered, but
> I'd be concerned about some default backing-store that might attempt
> enormous pixelmaps.

If JViewport uses a backing store at all, then only for the visible area.

I distantly remember some AWT problems with huge components (which the
JTable then is), but cannot reproduce them now.

Christian

Reply to this Message

Thomas G. Marshall - 11 Jan 2005 18:14 GMT

Christian Kaufhold coughed up:

> Thomas G. Marshall
> <tgm2tothe10thpower@replacetextwithnumber.hotmail.com> wrote:
[quoted text clipped - 21 lines]
>
> Christian

Thanks for your insight. You may have similar war wounds to the ones I
have.

Signature

With knowledge comes sorrow.

Reply to this Message

Huge JTables, nowadays...

Free Magazines