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
