AbstractTableModel (FireTableRowsInserted)

Tenho uma dúvida em relação aos parâmetros passados ao método fireTableRowsInserted(int firstRow, int lastRow), parâmetros estes de índices inteiros inclusivos.
Em todos os exemplo que vi na implementação de um TableModel, no método para se adicionar uma List à List de dados já existentes, é passado no parâmetro de “lastRow” o índice atual, ou, a soma do índice anterior ao tamanho da list à ser adicionada, algo como:

public void addListBeans(List bean) {
int index = getRowCount();
listLinhas.addAll(bean);
fireTableRowsInserted(index, getRowCount());
}

public void addListBeans(List bean) {
int index = getRowCount();
listLinhas.addAll(bean);
fireTableRowsInserted(index, index + bean.size());
}

Os exemplos que vi aqui no fórum estão sempre assim, porém o índice não começa no zero? Então não deveria ser feita a subtração de 1 no valor passado em “lastRow”? E se utilizado desta forma, caso a List passada por algum motivo esteja vazia seria necessário um IF antes de invocar o método? Algo como:
public void addListBeans(List bean) {
int index = getRowCount();
listLinhas.addAll(bean);
if (getRowCount() > 0)
fireTableRowsInserted(index, getRowCount() - 1);
// Se a List veio vazia nem precisa chamar o método
}

Utilizando o código sem a subtração do índice não gera nenhuma Exception, mesmo colocando um valor qualquer muito superior ao índice real em “lastRow”, porém ao adicionar um Sorter na JTable, o fireTableRowsInserted gera um IndexOutOfBoundsException.
Então qual seria a forma correta de implementação?
Obrigado pela atenção!

Se usar o método fireTableDataChanged() você não precisa se preocupar com os índices alterados.

Eu pensei em utilizá-lo, mas por este método atualizar a tabela inteira pensei que seria um consumo desnecessário. Quando utilizo a subtração e o IF para evitar o -1 ele funciona, porém não sei se seria um gambiarra ou uma má prática e achei estranho de nos exemplos não estar desta forma.

O Swing usa MVC ao extremo, quando você manda sua JTable se atualizar através do método fireTableDataChanged(), o “consumo desnecessário” acontecerá somente para as linhas visíveis na tela, as outras linhas são atualizadas sob demanda a medida que você rola a JTable.
Por isso que é tão bom ter o seu próprio TableModel e não usar o DefaultTableModel. :slight_smile:

Entendi. Bacana, não sabia que somente as linhas visíveis eram “recalculadas” em tempo real ao chamar o evento, e não todas as linhas. Obrigado pela informação!