Managing resources

One of the challenges in adopting SWT is that native resources must be freed when they are no longer needed. Unlike AWT or Swing, which perform these operations automatically when an object is garbage collected, SWT needs manual resource management.

Note

Why does SWT need manual resource management?

A common question asked is why SWT has this rule, when Java has had perfectly acceptable garbage collection for many years. In part, it's because SWT predated acceptable garbage collection, but it's also to try and return native resources as soon as they are no longer needed.

From a performance perspective, adding a finalize() method to an object also causes the garbage collector to work harder; much of the speed in today's garbage collectors are because they don't need to call methods, as they are invariably missing. It also hurts in SWT's case because the object must post its dispose request onto the UI thread, which delays its garbage collection as the object becomes reachable again.

Not all objects need to be disposed; in fact, there is an abstract class Resource, which is the parent of all resources that need disposal. It is this class that implements the dispose() method, as well as the isDisposed() call. Once a resource is disposed, subsequent calls to its methods will throw an exception with a Widget is disposed or Graphic is disposed message.

Further confusing matters, some instances of Resources should not be disposed by the caller. Generally, instances owned by other classes in accessors should not be disposed; for example, the Color instance returned by the Display class's getSystemColor() method is owned by the Display class, so shouldn't be disposed by the caller. Resources that are instantiated by the caller must be disposed of explicitly.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset