SWT API like Control.getBackground()
does not allocate a new native resource that needs to be dispose()d by
the caller (the Color.win32_new() javadoc could be misinterpreted to imply
otherwise). Such implementations may return a new Color object that
wraps the native resource, but a new native resource is not allocated.
You should never dispose() a graphic resource unless you originally
created it with "new ...". I think that you can get away
with over-dispose()ing a Color on win32 due to an implementation detail,
but doing this on other platforms or with other types of graphics resources
will cause problems.
Stephan Aßmus <superstippi@xxxxxx>
09/28/2011 03:22 PM
Inconsistent need of disposal of resources not directly allocated by client
Hello SWT team,
thank you for such a great framework!
I know that I am supposed to call dispose() on any resources such as
Fonts, Colors and Images, which I allocate myself.
Something that I find very troublesome in the API, and which you may
want to consider cleaning up and making consistent, is that it is not at
all clear when functions that return such resources have actually
allocated new copies. By pure coincidence, I have looked at the
implementation of Control.getBackground() and saw that it actually
returns a new Color which I am supposed to dispose().
The seemingly similar Control.getFont() however returns a Font which is
either the direct member of the Control, or the global system font of
the Display, both of which shall not be disposed, of course.
Maybe I am missing something, but this should really get documented
properly, or better yet, be made consistent (but I suppose it's
impossible, since existing applications would stop working correctly).
Since all those resources can actually not be modified, it would have
been most convenient for clients, if such resources were never supposed
to be freed.