On 24/09/2015 9:06 p.m., Dr. Michael Paus wrote:
Hi,
I wasn't aware of this Toolkit method when I wrote the mail you are
referring to. Can you or anybody
else explain what this method exactly does. It sounds indeed as if I
could solve some problems with
it although I am not sure yet and of course only if Jonathan does not
block it in the future :-)
Michael
To be fair, I am not actively blocking anything :-) The API _will_
disappear (because it is in com.sun.* and modules will make it
disappear, etc) unless a strong argument is made for the API. I'm merely
trying to open the door to the possibility that the API may _not_
disappear :-)
However...from the discussion so far, I don't think there is a good
argument to bring a public API out for this method. In many regards the
examples given are better resolved in alternative means (which you guys
have done a great job in discussing). The arguments against bringing
firePulse() into public API were well summarised in a few of the emails:
1) firePulse() is actually ill-defined. As Kevin notes all the
firePulse() does is actually call all the pulse listeners (stage, scene,
and post-scene). The toolkits have better defined semantics, but they
all eventually end up calling firePulse() once they've done The Right
Thing. To correctly define the semantics is not a hugely trivial task,
and to rework the toolkits to work within these semantics may not be
trivial either.
2) A common argument for calling firePulse() is that, well, something is
broken (either in JavaFX or in the application code), and the easiest
path to fix this is to force a pulse. The better solution is to find why
this is broken and to resolve it. I used to call this a lot as a
stop-gap measure, but it always smelled to me. I would like to encourage
people think of calling this as a code smell too. It should say to you
that something is wrong somewhere....
3) The primary valid use case is unit tests, and for now we don't think
exposing such a risky piece of API in a rushed way will bode well, if
unit tests are the primary argument for this API. In addition to this,
with JDK 9 there will still be the runtime switch to enable access to
com.sun.* API, so people running unit tests will still be able to use
this API whilst leaving a longer runway for resolving how such as an API
may be exposed (if at all).
This isn't a closed issue yet - there is still scope to discuss this,
but the default position Kevin and I are taking now (based on my JDeps
analysis of the communities code, as well as these discussions) is that
firePulse() will not be public API for JDK 9.
Thanks,
-- Jonathan
