A question about the lifecycle of a GC object

[ptziegler]

This is about a weird little thing that just came up in the GEF project. Let's consider the following simplified snippet:

public static void main(String[] args) {
	Shell s = new Shell();
	GC gc = new GC(s);
	s.dispose();
	gc.dispose();
}

Executing this code fails with a "Widget is disposed" error, because the containing Shell is disposed before the GC instance. However, gc.isDisposed() still returns false.

My question: What is the expected behavior here? Is there a different way to check whether the GC object is still valid and how would I destroy it?

As a workaround, I can write this:

public static void main(String[] args) {
	Shell s = new Shell();
	GC gc = new GC(s);
	s.addDisposeListener(event -> gc.dispose());
	s.dispose();
	gc.dispose();
}

But this obviously doesn't answer the original question.

[HeikoKlare]

My guess why this was not detected earlier: GCs on controls will/should probably be quite short-living. They are, e.g., used for screenshotting with a very limited lifecycle, such that a control (including a shell) may not be disposed during the lifecycle of the GC on top of it. This could even be an implicit contract (GC must be disposed before the underlying drawable), but I don't think there is any explicit specification requiring it.

So regarding your question: I don't think there is any proper way to detect that a (non-disposed) GC currently operates on an already disposed drawable. As mentioned above, I think this scenario is still not considered (explicitly or by accident). Maybe someone else knows if an explicit specification already exists.
If not, we can collect what the expected behavior is or should be. I see multiple options to improve this:

• Make the implicit contract (GC must be disposed before the drawable/control it was created on): This would simply reflect the existing behavior, so that it's not really a contract change but just makes the existing contract explicit. However, it would conflict with the fact that for GCs on images, it's best to not dispose the GC before the image to allow re-rendering the image for different zooms.
• Dispose the GC when the drawable is disposed: This would align with how it already behaves for images. But this would be a behavioral change as GCs that used to be non-disposed may not become disposed (such as in the scenario you describe and that happens in Draw2d)
• Gracefully deal with the situation that the underlying drawable is already disposed when disposing the GC: looking at the different Drawable specializations, this only seems to be an issue for Controls, which do a checkWidget(). So we could either check the disposed state of the underlying drawable inside GC (and then not try to dispose it) or we could validate if the checkWidget() is really valid/necessary here or if we couldn't just return from the internal_dispose_GC() method if the control is already disposed. The former would be less "invasive" but require an instanceof check. And this only covers the dispose case, but there is of course a bunch of other operations that can be called on a GC and might fail when the underlying drawable is already disposed, so this is probably not a good way to go.