Usage of Toolkit firePulse

[Jonathan Giles]

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