You can see this problem in one of the Visual Library demos:

test.component.ComponentTest

Drag a component on top of another component and you will see the that the swing components "bleed through" the widgets.

Note: widget.setOpaque(true) does not solve this problem.  Without a fix for this, the visual library is useless for
anyone serious about embedding swing components into a scene.

It looks like the swing components "bleed through" because they (the swing components inside ComponentWidget) get added
directly as children to the scene's view:

Code:
scene.getView ().add (component);


Here's the full method from ComponentWidget:

Code:

    private void addComponent () {
        Scene scene = getScene ();
        if (! componentAdded) {
            scene.getView ().add (component);
            scene.getView ().revalidate ();
            component.addComponentListener (componentListener);
            componentAdded = true;
        }
        component.removeComponentListener (componentListener);
        component.setBounds (scene.convertSceneToView (convertLocalToScene (getClientArea ())));
        component.addComponentListener (componentListener);
        component.repaint ();
    }


This means they (the swing components) have a different z-order than the widgets.

This also means that if you want to "bring to front" a widget with a swing component, this method must be overridden and
the component must be added as a child with index 0 (on the parent).

It would be great if this could be fixed so that the swing components get painted within the widget (instead of by the
scene view's paintChildren method). There is a paintWidget() method on the ComponentWidget, but it does not appear to be
painting the swing components the way that they were intended to painted.

When this is fixed, please check it with a JTable or JList with a custom renderer. My fix still allows the renderers to
"bleed through" the other swing components (when their parent widget is dragged over another swing component).

Also, can you remove the "final" from the bringToFront/Back() methods.