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
