I don't see what the problem is? Why must you reduce the visibility? You wouldn't do that for any other public method you've overridden? That would be clinging to a memory of what the API used to be. I would understand if I had to set my protected method public after updating my jdk - it's necessary to improve things. Why must we suffer for all of time just because some API designer wasn't "omniscient" in the beginning? Code must evolve or we might as well go back to swing - we're already making a hugely painful and inconvenient investment in time by putting off the next release for over 6 whole months. Frankly, adopters aren't falling out of the sky and we need to protect the future of fx by having sturdy code coming out of the gate. The decisions made now are imminently more crucial than you might think.
</end speach> Sorry but it was an opportune time... Retiring thumbs, David Sent from my iPhone On Jul 9, 2013, at 12:28 AM, Tom Schindl <[email protected]> wrote: > On 09.07.13 04:10, Jonathan Giles wrote: >> Hi all, >> >> This request is to change the API for Cell.updateItem(T item, boolean >> empty) from protected to public. Clearly this will not be a breaking >> change, but it does make the API more public than ideal :-) > > This is a breaking change. If I subclassed Cell and overloaded it (still > leaving it protected) I'll then get a compiler error because I can't > reduce visibility in a subclass. > > Tom >
