Hi, I must not (although most of the code out there which specialized Cell kept it protected and hence is broken) and all I did was to point out that this is and will be a breaking changeing.
Whether this justifies breaking code is up to the openjfx team, simply saying it does not break compatibility to get some API approved is not the way to go. Tom On 09.07.13 15:17, David Ray wrote: > 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 >>
