[API Review] RT-27887: introduce a node to embed Swing into JavaFX

[Mario Torre]

Il giorno ven, 25/01/2013 alle 23.30 +0400, Artem Ananiev ha scritto:

> Just imagine the code that creates a SwingNode and its content:
> 
> public void start(Stage stage) {
>    Scene scene = ...;
>    final SwingNode swing = new SwingNode();
>    scene.getRoot().getChildren().add(swing);
>    stage.setScene(scene);
>    stage.show();
> 
>    SwingUtilities.invokeLater(() -> {
>      JComponent content = ...;
>      swing.setContent(content);
>    });
> }
> 
> If we require setContent() to be called on FX thread only, the last part 
> of the code above will become a little bit more ugly:
> 
>    SwingUtilities.invokeLater(() -> {
>      final JComponent content = ...;
>      Platform.runLater(() -> {
>        swing.setContent(content);
>      });
>    });


This is what we did for the ThingsFX integration component, and a
typical test application looks like this:

https://github.com/thingsfx/ThingsFX/blob/master/src/test/java/com/thingsfx/examples/swing/MultipleSwingViews.java

Which is indeed ugly, but mixing of two different paradigms always come
at this cost.

I was under the impression that we were missing something here, though.
I never sorted this feeling out completely, but perhaps we should add
some kind of helper class to make this code a bit easier on the eye.

For example something that calls for us the invokeLater stuff in the
appropriate places (names here just for sake of clarity):

interface JComponentBuilder {
    JComponent build();
}

SwingNode.setContent(JComponentBuilder builder);

The Swing component would know on which thread to call what. An even
better approach would be to have this helper outside the SwingNode in a
separate helper class to have even more modularization.

This is something anybody can do in their own code anyway, so maybe it's
not worth to add it to the API.

I would expect that the typical use case for Swing integration is the
reuse of custom components but even more of entire portions of existing
applications, so it's likely that developers will have already some
abstractions in place to create their JComponents. [1]

Cheers,
Mario

[1] But once again, the whole point of this discussion is to reduce the
impact of the threading systems, which are indeed implementation
details, to the developer that are less fond of those caveats... Those
guys will probably already have a messed up application :)