• Post Reply Bookmark Topic Watch Topic
  • New Topic

How does the state of a component survive a call to Window.dispose?

 
Stevens Miller
Bartender
Posts: 1422
29
C++ Java Netbeans IDE Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A lot of the time, when I want a window to depart from my screen, I just set its visibility to false, setting it back to true when I need it again. But, other times, I want the window to give back any resources it is consuming when it's not visible. If I need it again, I create a new one.

So, I'm re-reading the Window.dispose method's javadoc, where it says this:

Oracle wrote:
public void dispose

Releases all of the native screen resources used by this Window, its subcomponents, and all of its owned children. That is, the resources for these Components will be destroyed, any memory they consume will be returned to the OS, and they will be marked as undisplayable.

The Window and its subcomponents can be made displayable again by rebuilding the native resources with a subsequent call to pack or show. The states of the recreated Window and its subcomponents will be identical to the states of these objects at the point where the Window was disposed (not accounting for additional modifications between those actions).[emphasis added]

I'm confused as to how the states of "recreated" objects can be identical to what they were when the Window was disposed. The previous paragraph of the javadoc has me thinking all those components would have been destroyed, same as any object for which no code was still holding a reference.

How can the state of a recreated object be the same as its destroyed predecssor? Do they mean I can keep the predecessor if I want to, and re-use it? If so, what's that whole paragraph that says Components will be destroyed mean?
 
Stephan van Hulst
Bartender
Posts: 6583
84
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm assuming it just releases the native resources, such as video memory, and other handles it may have into the system.

The memory used by the object itself will obviously still remain present. After you make the component visible again, it will recreate the state the component was in before you disposed it. This state can be inferred from the 'configuration' that is represented by the Java object itself.
 
Brett Spell
Ranch Hand
Posts: 118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The key to understanding this is to realize that "top-level" (a.k.a. "heavyweight") / window components are represented by two entities: the Java (e.g., JFrame) object, and a counterpart (or "peer") that's managed by the native operating system. It's the "native peer" that you actually see, and the Java object is really just a wrapper around it. Calling dispose() releases the resources associated with the peer, but otherwise doesn't really affect the state of the Java object. The Java object contains information like the title, size, location, etc., so it can easily be used to create a brand new peer later with the same state as the original.
 
Stevens Miller
Bartender
Posts: 1422
29
C++ Java Netbeans IDE Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Brett Spell wrote:The key to understanding this is to realize that "top-level" (a.k.a. "heavyweight") / window components are represented by two entities: the Java (e.g., JFrame) object, and a counterpart (or "peer") that's managed by the native operating system. It's the "native peer" that you actually see, and the Java object is really just a wrapper around it. Calling dispose() releases the resources associated with the peer, but otherwise doesn't really affect the state of the Java object. The Java object contains information like the title, size, location, etc., so it can easily be used to create a brand new peer later with the same state as the original.

Got it. Thanks!
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!