<AWT Dev> [OpenJDK 2D-Dev] What to override and what now

[Jim Graham]

It's even messier than that.  It essentially specifies exactly how the 
value is determined and there is not only no need to override it - doing 
so just opens the door to violating its spec.

Both XToolkit and WToolkit have the exact same implementation which 
complies with the documentation for the method.  That implementation 
should be copied up into this method rather than having it return a 
fixed value.

Arguably, it should have been final, or the spec should have been left 
open if it was really intended to be overridden and platform-specific.

If it is changed to return a static answer then the documentation should 
be updated to loosen its language so that the indicated behavior is the 
suggested behavior, but the true behavior is left open to the platform...

			...jim

On 10/26/2011 10:22 AM, Roman Kennke wrote:
> Hi Artem,
>
>>> While working a bit on cacio, we just found some new nice addition to the Toolkit code, like this one:
>>>
>>>       public boolean areExtraMouseButtonsEnabled() throws HeadlessException {
>>>           GraphicsEnvironment.checkHeadless();
>>>
>>>           return Toolkit.getDefaultToolkit().areExtraMouseButtonsEnabled();
>>>       }
>>>
>>> Of course, this method is meant to be overridden, so it will end up doing nothing, but things like this may be very difficult to debug at times, and in any case, is definitely are not friendly code. Is there any reason for this smartness?
>>
>> I completely agree. This code seems to be never called, otherwise it
>> would fail into an infinite recursion, it shouldn't be any problems with
>> it returning "false".
>
> Why not make it throw an exception? This way it would be very easy to
> find out what is wrong. Returning null, false, -1 etc might make your
> code blow up much later and it takes some debugging to figure out what
> is wrong.
>
>>> Why not simply provide a default implementation or just throw an exception or simply make the method abstract? Or maybe I'm missing something?
>>
>> Making it abstract is not a good idea: I know some rare cases when the
>> Toolkit class is extended (e.g. for testing purposes), and adding a new
>> abstract method will break such code at compile time.
>
> Yeah agreed. We are doing this massively in Cacio as you can imagine,
> and for us would be nicer to have a compile time error so we know what
> to fix. But I see that java.awt.Toolkit is public API and cannot be
> changed in a non-compatibel way...
>
> Cheers, Roman
>
>