Hi,
A second apology is needed: I had sent this from the wrong email
account, so it got blocked for moderation. By the time I'd realised that
wasn't normal / something was wrong, it was past the 3-day limit to
cancel it. The discussion had progressed by then, and I'd more or less
convinced myself the current fix & javadoc is good.
So feel free to ignore my email.
Kind regards,
Luke
On 23/06/2017 12:07, Luke Usherwood wrote:
Hi,
Sorry for the late reply - I've been travelling. As the bug reporter,
would you mind if I gave a few passing thoughts?
On 6/20/2017 11:16 PM, Semyon Sadetsky wrote:
> Hi Prasanta,
>
>So, it is better check whether the model is a DefaultButtonModel and
skip if grouping is not supported. Or, perhaps, it is reasonable to
pull up the > getGroup() into the ButtonModel interface which already
has setGroup().
On one hand, it seems the best default methods are the ones able to
produce correct behaviours w.r.t. the other interface methods when
retrofitted, to avoid any 'surprises'. For example if some other code
decides to switch from DefaultButtonModel to accept any ButtonModel -
that would happily compile but it might be easy to miss the changed
semantics: that calling getGroup may not necessarily give back a value
passed in to setGroup any more, and hence there's scope for a subtle
runtime crash bug to be introduced.
Also, would the change that pulls up a new default method into
ButtonModel be permitted if this fix were back-ported to JDK-9?
On the other hand I suppose there's no other choice if you want to
patch this oversight in the interface design (which looks like it was
wanted since Java 1.3!) ... so this is the trade-off you've taken. The
likelihood of an actual crash in practice is low, and more so because
most calling code would test for a null value anyway. So I guess on
balance this may be reasonable.
If you do proceed with default method solution...
1) should the javadoc for state that all implementers are expected to
override the default implementation of getGroup(), and callers should
always test for a null value (even when that might not be expected) to
account for legacy implementations where the method might not be
implemented?
2) will you change similar code in the JDK - such as found in
JToggleButton.getGroupSelection() - to avoid the check-and-cast to
DefaultButtonModel. This would seem required to ensure that all
ButtonModels implementing getGroup() are treated consistently to other
DefaultButtonModel instances.
Kind regards,
Luke
