• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Bartender
Posts: 1464
32
Netbeans IDE C++ Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
Saloon Keeper
Posts: 15510
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 118
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 1464
32
Netbeans IDE C++ Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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!
 
reply
    Bookmark Topic Watch Topic
  • New Topic