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
