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
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).