Managing resources
One of the challenges in adopting SWT is that native resources must be disposed 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 pre-dates 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 is 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 until the object becomes reachable again.
Not all objects need to be disposed; in fact, there is an abstract class called 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 Resource
instances 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
method getSystemColor
is owned by the Display
class, so it shouldn't be disposed by the caller. Resource
objects that are instantiated by the caller must be disposed of explicitly.