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
