ViniGodoy wrote:Ah sim, claro. Você quis dizer que o JInternalFrame são janelas lightweight. Já que janelas são, tipicamente, os únicos componentes heavyweight do Swing.
Aí faz todo sentido.

Na verdade, foi o que pensei poucos segundos após postar para vc a resposta.

ViniGodoy wrote:Não percebi que você falou em "componente leve" se referindo a lightweight. Até porque, todos os componentes do Swing são lightweight, e não só o JInternalFrame:
http://docs.oracle.com/javase/1.4.2/docs/api/javax/swing/package-summary.html

The only heavyweight components used in Swing are:

swing.JFrame
swing.JDialog
swing.JWindow
swing.JApplet
All AWT components (awt.*), except those noted below.

ViniGodoy wrote:Não percebi que você falou em "componente leve" se referindo a lightweight. Até porque, todos os componentes do Swing são lightweight, e não só o JInternalFrame:
http://docs.oracle.com/javase/1.4.2/docs/api/javax/swing/package-summary.html

Não entendi o que você quis dizer com o stackoverflow ter mais moderação. Nossa discussão foi estritamente técnica, e encontra-se discussões desse tipo por lá também. Eu não me senti ofendido, nem irritado, pelos seus comentários, e nem "trocamos elogios".

De fato, eu concordo com muitos dos seus argumentos, como o fato de não ficar nulificando variáveis locais, e não ficar otimizando sem um profiler. Inclusive, já dei as mesmas dicas aqui no GUJ, para bastante gente. E sou um grande fã dos artigos do Goetz.

Entretanto, eu só estava deixando claro como funciona o mecanismo de liberação das janelas, sem entrar no mérito de se isso seria ou não uma boa prática sempre. É um erro muito comum acreditar que o dispose() libera toda a memória ocupada por uma janela, mesmo aquela pertencente à VM (como se ele magicamente ampliasse as capacidades do coletor de lixo).

ViniGodoy wrote:Você deve setar como null porque aquela variável não sai do escopo. Se o menu tiver 50 janelas, e cada uma for aberta uma vez, haverá 50 janelas na memória ao final do processo, mesmo que todas tenham sido fechadas!

De qualquer forma, com o que você falou, só vai haver a coleta da memória da janela anterior, quando a nova for aberta. Ou seja, no sistema, haverá pelo menos uma janela daquele tipo ocupando memória, a partir do momento que ela for aberta a primeira vez.

ViniGodoy wrote:

ceklock wrote:O negócio é o seguinte. Salvo alguma rara exceção, na grande maioria dos casos não é necessário setar uma variável como null. A máquina virtual sabe muito bem quando uma variável/atributo não é mais usado por ninguém.

Eu só discordo de que isso seja exceção, e mais ainda que seja raro.
Já atendi dezenas de tópicos no GUJ com exatamente esse problema.

Se você tem um JFrame assim (como o Visual Editor sugeria):
public class Menu { private Janela1 janela1; ... public void abrirJanela1() { if (janela1 == null) { janela1 = new Janela1(); janela1.setVisible(true); } } }

Você já terá que deixar janela1 null após o dispose(). É ainda mais comum no caso de ser um JInternalPane, uma vez que ele é associado a um DesktopPane. O dispose() não remove a janela do DesktopPane e, portanto, uma referência como a acima se faz necessária. É também necessária uma atitude explícita do programador.

ViniGodoy wrote:Ceklock, como falei 3 vezes nesse tópico, não estou falando de definir variáveis que saem de escopo para null. Mas variáveis que se mantém no escopo, como no exemplo que citei anteriormente.

Definir variáveis que saem de escopo para null é desnecessário, pois essas variáveis deixarão de existir.

Aliás, o texto que você linkou, fala exatamente disso:

There is one case where the use of explicit nulling is not only helpful, but virtually required, and that is where a reference to an object is scoped more broadly than it is used or considered valid by the program's specification.

Explicit nulling

Explicit nulling is simply the practice of setting reference objects to null when you are finished with them. The idea behind nulling is that it assists the garbage collector by making objects unreachable earlier. Or at least that's the theory.
There is one case where the use of explicit nulling is not only helpful, but virtually required, and that is where a reference to an object is scoped more broadly than it is used or considered valid by the program's specification. This includes cases such as using a static or instance field to store a reference to a temporary buffer, rather than a local variable, or using an array to store references that may remain reachable by the runtime but not by the implied semantics of the program. Consider the class in Listing 3, which is an implementation of a simple bounded stack backed by an array. When pop() is called, without the explicit nulling in the example, the class could cause a memory leak (more properly called "unintentional object retention," or sometimes called "object loitering") because the reference stored in stack[top+1] is no longer reachable by the program, but still considered reachable by the garbage collector.

Listing 3. Avoiding object loitering in a stack implementation
public class SimpleBoundedStack { private static final int MAXLEN = 100; private Object stack[] = new Object[MAXLEN]; private int top = -1; public void push(Object p) { stack [++top] = p;} public Object pop() { Object p = stack [top]; stack [top--] = null; // explicit null return p; } }

In the September 1997 "Java Developer Connection Tech Tips" column (see Resources), Sun warned of this risk and explained how explicit nulling was needed in cases like the pop() example above. Unfortunately, programmers often take this advice too far, using explicit nulling in the hope of helping the garbage collector. But in most cases, it doesn't help the garbage collector at all, and in some cases, it can actually hurt your program's performance.

entanglement wrote:Uma curiosidade.

Crie um programa que aloque 100 strings cada uma ocupando 1 MB de memória (ou seja, cada uma delas contém 500 mil caracteres). Ponha-as em um array e imprima a quantidade de memória usada pelo programa. Para garantir que é a memória mesmo, antes de imprimir, execute um System.gc, espere 2 segundos, e entáo execute outro System.gc.

A seguir, crie um outro array de 100 posicóes contendo substrings dessas strings grandes (digamos da pposiçao 1000 até a 2000). Imprima a mem[oria usada. Você deve ver que a quantidade praticamente não se alterou.

Então, limpe o primeiro array (aquele das strings grandes). Execute um System.gc e veja quanta memória está sendo usada.

Perguntas:
1) a quantidade de memória usada caiu ou não?
2) Por que é que isso ocorreu? (Dica: leia o fonte da classe String, método substring)
3) Como evitar esse problema esquisito?

entanglement wrote:
O "garbage collector" lida com apenas um tipo de recurso finito, que é a memória usada por seu programa. Não é atribuição dele sair limpando outros tipos de recursos.

lina wrote:

ceklock wrote:

lina wrote:Oi,

A principio, isso me parece um ponto negativo da linguagem (eu não esperava ter que dizer isso um dia).

O Java ou a linguagem deveria interpretar que determinado comando, como o dispose(), deveria remover toda a referência do objeto. A não ser que exista uma razão muito complexa para que isso não aconteça. (?!)

Tchauzin!

dispose() não faz isso? Pelo que pude entender até agora toda a janela e os componentes associados a ela são liberados da memória.

Oi,

Eu entendi ao contrário...

Exemplo:

Janela teste = new Janela().setVisible(true);

Fechando:

Janela teste = new Janela().setVisible(true); teste.dispose();

Liberando da memoria:

Janela teste = new Janela().setVisible(true); teste.dispose(); teste = null;

Tchauzin!