Ah, saquei sua dúvida!
Assim: Existe um ArrayList na memória, certo? Vamos chamar esse ArrayList alocado na memória apenas de objAL, ok? Só pra facilitar. dados e list serão chamadas de referências, blz?
Lá naquele seu primeiro exemplo, nós temos, em um tal método createJTable, a seguinte linha de código
ArrayList dados = new ArrayList()
O que acontece aqui? São criadas duas “coisas”, basicamente, nesse momento: uma referência chamada dados e uma instancia de um objeto ArrayList, que no caso é o nosso objAL. Perceba que a referência dados e o objAL estão associados. É através da referência dados que conseguimos manipular o objAL(Como pode ser visto através da invocação do método add, por exemplo). Quando passamos a referência dados para o construtor da SimpleTableModel, o objAL passa a estar associado com duas referências: com a dados que foi declarada no método createJTable, e também com a dados, diferente da primeira, declarada na assinatura do construtor da classe SimpleTableModel.
O construtor, por sua vez, invoca o método setLinhas(ArrayList), e passa a referência dados por parâmetro. Isso agora faz com que objAL esteja associado com 3 referências: dados de createJTable(…), dados de SimpleTableModel(…) e list de setLinhas(…). O método setLinhas(…) faz esse número aumentar pra 4 quando ele, atravez da instrução …
… associa o objAL também a referência linhas, que é um atributo da classe JTableModel.
Agora é o momento em que sua dúvida toma lugar, pois logo após esta intrução, o método setLinhas(…) é encerrado e list “morre”. Perceba que list não é a instância para o ArrayList, é apenas um referência para tal instância, é apenas uma referência para o nosso objAL. Imagine que o objAL é um balão que tem infinitas cordas a ele amarrado, e que cada referência é uma mão que segura uma corda qualquer dessas. Quando o método setLinhas(…) é encerrado, a única coisa que acontece com o objAL é que a sua “corda” que estava sendo segurada pela referência list é “solta”; list “solta” objAL depois de “morrer”. Da mesma forma, dados(do construtor da SimpleTableModel) vai também soltar a corda quando o construtor terminar sua execução e retornar o controle para o método createJTable. Neste exato momento momento, lá no método createJTable, a referência modelo é associada a uma instância de SimpleTableModel(implementação da dita classe lá na memória, da mesma forma que o nosso objAL). Nesse momento, como estão as “cordas” do objAL? Assim: uma está sendo segurada pela referência dados, que pertence ao método createJTable, e uma segunda corda está sendo segurada pela referência linhas, que por sua vez está contido dentro da referência modelo(pois linhas é um atributo da classe cuja determinada instância está associada a modelo).
Quando o método createJTable terminar, a referência dados vai morrer e, assim, largar sua “corda”, desassociar-se do objAL. Daí então podemos ser levados a pensar…
“hlds”:
[…]dps q o metodo createJTable termina ai o ArrayList dados eh destruido e daria pau no ArrayList linhas (q estaria apontando p msm area q foi apagada c a finalizacao do createJTable)[…]
Isso não ocorre! Por quê? Simples: objAL, sendo um “balão”, só se perderá quando ninguém mais o estiver segurando, o que não necessariamente está acontecendo…
Um pouco ante de o createJTable(…) terminar, ele pegou a referência
modelo e passou pro construtor da JTable, que por sua vez, internamente, vai “segurar uma corda” da intância de SimpleTableModel referenciada pela referência
modelo. Quando o createJTable termina, ele retorna para seja-lá-quem-for-que-o-invocou a referência “jtable”, a qual está associada, está segurando a corda de uma instância da classe JTable.
Vamos supor que o método
seja-lá-quem-for-que-invocou-o-createJTable tenha feito a invocação do createJTable(…) com a linha…
JTable myTable = createJTable(...);
Nesse caso, aquela referência jtable(do createJTable(…)) morre, larga a corda, e myTable pega uma corda e segura a instancia de JTable. Segura JTable, que segura SimpleTableModel, que segura ArrayList, e este ArrayList é o nosso objAL.
Conseguiu ver por que aquilo que vc imaginou não acontece? Percebe que o “balão” do ArrayList, o objAL, não foi largado em nenhum momento desde sua criação?
Mas agora vc pode perguntar: “P@$*#! Mas isso não é passagem por referência!!?”
Não é. Pelo menos não como é a dita passagem em C e C++. Como assim? Vamos olhar para o construtor SimpleTableModel(ArrayList dados,…) e para o método setLinhas(ArrayList list). Suponha que o código do setLinhas(…) seja assim:
list = new ArrayList(0);
linhas = list;
Se em Java tivesse passagem por referência, como há no C/C++, o nosso objAL, que tinha vários elementos(“São Paulo”, “Rio de Janeiro”, etc), passaria a ser agora um ArrayList vazio. Mas isso não acontesse em Java. O que aconteceria se o código acima fosse o código do setLinhas(ArrayList list), seria a referência list largar o balão objAL, que lhe foi entrege pela referência dados(do construtor), e pegar a corda de um outro balão(associar-se a uma outra instância de ArrayList, uma que tem 0 posições) e passar esse balão pra referência “linhas”(atributo da classe SimpleTableModel). Quando o controle voltar ao contrutor, a sua referência dados ainda vai estar segurando objAL, mas a referência que representa o atributo linhas vai estar segurando um outro ArrayList, que naum tem nada a ver com o objAL.
Espero que tenha ajudado, ou pelo menos não complicado mais ainda as coisas… :lol:
Qq coisa, poste mais, ok? :thumbup:
