Hello Luke,
DefaultButtonModel ::getGroup has never been being required to return
not-null. Can you clarify which new pitfall is introduced by the fix, so
that we should specify it explicitly?
--Semyon
On 06/28/2017 08:29 AM, Luke wrote:
Hi Semyon,
On 28/06/2017 16:59, Semyon Sadetsky wrote:
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.
Not sure that I fully understood this. According to the spec there is
the only group the button belongs to, and this group should be
returned in getGroup().
The spec can of course only apply to code written in Java 10+, legacy
implementations ButtonModel will still return null.
So say a helper function in a shared library does an "instanceof
DefaultButtonModel" check, and that it calls both
setGroup(ButtonGroup) and getGroup() - and for whatever reason pulls
the group back out rather than storing it in a local variable.
When porting that library to Java 10, a programmer might think "great,
now I can support all ButtonModels" and drop the instanceof check.
Some other app not yet ported to Java 10 passes that utility method a
custom ButtonModel, as it has always done. Instead of the utility
function doing nothing with it, it now throws a NPE.
I just raised this because I know how ultra-concerned the JDK is with
compatibility - but even by the JDK's high standards it does still
seem like a fairly theoretical-only issue.
Is the @implSpec already sufficient warning to a programmer porting
code to Java 10 to always deal with the null possibility? Perhaps it is.
Kind regards,
Luke
