Why is subclassing not allowed for many of the SWT Controls?

RAY picture RAY · Nov 24, 2010 · Viewed 8.4k times · Source

I often find myself wanting to do it. It can be very useful when you want to store some useful information or extra states.

So my question is, is there a very good/strong reason why this is forbidden?

Thanks

EDIT: Thanks a lot for all these answers. So it sounds like there's no right-or-wrong answer to this.

Assuming I accept the fact that these classes are not to be subclassed, what's the point of not marking a Control class final, but prohibiting subclassing - effectively demoting the exception/error from compile-time to run-time?

EDIT^2: See my own answer to this: apparently, these classes are overrideable, but requires explicit acknowledgement by the overrider.

Thanks

Answer

RAY picture RAY · Dec 5, 2011

It doesn't look like anybody mentioned this in any of the answers, but SWT does provide an overrideable checkSubclass() method; precisely where the Unextendable exception is thrown. Override the method to a no-op and effectively make extending legal. I guess to leave this option open is ultimately the reason that the class is not made final and the extension error not made compile-time instead of run-time.

Example:

@Override
protected void checkSubclass() {
    //  allow subclass
    System.out.println("info   : checking menu subclass");
}