Necessity of com.sun.javafx.embed.AbstractEvents

Artem Ananiev artem.ananiev at
Fri Sep 16 22:12:57 UTC 2016

Hi, Alexander,

I believe I introduced that extra abstraction layer for FX/Swing events 
long time ago. At that time, we thought we might eventually want to 
embed different components than just JavaFX, but it doesn't make any 
sense these days. JFXPanel and FXCanvas contain a lot of FX specific 
code, they can't be used to embed anything than FX. I agree that 
AbstractEvents is redundant and can be replaced by FX events.

BTW, SwingNode (which is opposite to JFXPanel, it's to embed Swing into 
FX) doesn't use AbstractEvents, but operates directly with FX events.



On 9/16/16, 2:03 AM, Alexander Nyssen wrote:
> Hi Alexander Z., Kevin,
> while working on JDK-8143596 (FXCanvas does not forward touch
> gestures to embedded scene) I came across some „smell“ that I would
> like to discuss. That is, the information about events that is
> exchanged between JFXPanel/FXCanvas and the
> EmbeddedScene/EmbeddedStage is currently encoded via constants of
> com.sun.javafx.embed.AbstractEvents. That is, FXCanvas and JFXPanel
> map SWT and AWT event information to constants in AbstractEvents,
> which are finally mapped to a JavaFX representations within
> EmbeddedScene.
> Without knowing the motivation behind this indirection, and without
> having tried it in detail yet, for me it seems as if AbstractEvents
> was superfluous and JavaFX representations could directly be used to
> transfer this information instead. In case of
> EmbeddedSceneInterface#inputMethodEvent() for instance,
> AbstractEvents was already bypassed, as here EventType is used as a
> parameter (instead of an AbstractEvents constant). Also, the modifier
> constants defined within AbstractEvents are only used in case of key
> events, while for mouse (and now gesture events) boolean parameters
> are used to transport this information (which could also be done in
> case of key events).
> What do you think? In case you share my assessment I would propose to
> file a separate issue for this, and I could offer to investigate it
> after JDK-8143596 has been resolved (I would not want to mingle it).
> Best Regards,

> Alexander

More information about the openjfx-dev mailing list