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.