Używałem tradycyjnej JavyTableCellRenderer podejście do dostarczania renderers wscala.swing.Table gdzie ogłaszam moje renderery na stoleTableColumnModel. Kod tego wygląda jak:

val myTable = new Table {
  lazy val tcm = initColumnModel
  peer.setColumnModel(tcm)

  override 
  protected def rendererComponent(sel: Boolean, foc: Boolean, row: Int, col: Int) = {
    //GET THE VALUE FROM THE TableModel
    val value = model.getValueAt(
                        peer.convertRowIndexToModel(row), 
                        peer.convertColumnIndexToModel(col))
    //GET THE RENDERER FROM THE ColumnModel
    val renderer = tcm.getColumn(col).getCellRenderer
    //WRAP IN A COMPONENT
    Component.wrap(renderer.getTableCellRendererComponent(
                        peer, 
                        value, 
                        sel, 
                        foc, 
                        row, 
                        col).asInstanceOf[JComponent])
   }
}

Niestety wydaje się, że ma to przeciek pamięci - prawdopodobnie dlatego, że tworzę nową instancję Component dla każdej komórki w tabeli (dla ~ 30k wierszy). Z pewnością, gdy wymieniam mój stół scala naJTable (używając dokładnie tego samegokolumna idane modele) mój wyciek pamięci znika.

Moje pytanie brzmi zatem, jakiego rodzaju kodu używają ludzie, gdy nadpisująrendererComponent metoda zakładająca, że ​​ktoś ma własne renderery komórek?