On Mon, 2 Mar 2020 11:47:03 GMT, Nir Lisker <nlis...@openjdk.org> wrote:
>>> >>> >>> I think that a starting point would be to decide on a spec for the listener >>> notification order: is it specified by their registration order, or that is >>> it unspecified, in which case we can take advantage of this for better >>> performance. Leaving is unspecified and restricting ourselves to having it >>> ordered is losing on both sides. >> >> technically true - but the implementation was linear with a fixed sequence >> since-the-beginning-of-java-desktop-time (and sometimes, for good ol' beans >> properties, even exposed as api to access the array of listeners). So >> technically, we could go the path of explicitely spec'ing that the order is >> unspecified. Pretty sure that doing so and implementing it will break tons >> of application code that's subtly relying on fifo notification (f.i. >> register before or after skin has its own is a simple wide-spread trick) .. >> which all did it wrong and might deserve it ;-) But then if even internal >> code does it .. > >> technically true - but the implementation was linear with a fixed sequence >> since-the-beginning-of-java-desktop-time (and sometimes, for good ol' beans >> properties, even exposed as api to access the array of listeners). So >> technically, we could go the path of explicitely spec'ing that the order is >> unspecified. Pretty sure that doing so and implementing it will break tons >> of application code that's subtly relying on fifo notification (f.i. >> register before or after skin has its own is a simple wide-spread trick) .. >> which all did it wrong and might deserve it ;-) But then if even internal >> code does it .. > > So we can choose to specify it as ordered. > > These are the 2 options I mentioned: > 1. Not specify the behavior and change the implementation in favor of > performance. This could break applications as you've mentioned. > 2. Specify that the order is preserved and keep the ordered implementation > behavior. This will allow applications to rely on the behavior safely. > > Right now we're losing on both sides. We keep a promise and we don't tell > anyone about it. The only reason for this is if we intend to change the > behavior in the future, in which case we should add a doc comment saying that > the order is unspecified and is planned to change in the future, so there > will be at least some warning. > > Once we choose what to do here it will make sense to continue to review the > code with that decision in mind. In a minimal test I wrote (not a microbenchmark that removes listeners), I tried this PR code, but did not reproduce the performance improvement. I have attached a test program in my PR(#125) ------------- PR: https://git.openjdk.java.net/jfx/pull/108
