Class SJPanel

java.lang.Object
com.vaadin.flow.component.Component
com.vaadin.flow.component.HtmlComponent
com.vaadin.flow.component.HtmlContainer
com.vaadin.flow.component.html.Div
com.vaadin.swingbridge.surrogates.SJPanel
All Implemented Interfaces:
com.vaadin.flow.component.AttachNotifier, com.vaadin.flow.component.ClickNotifier<com.vaadin.flow.component.html.Div>, com.vaadin.flow.component.DetachNotifier, com.vaadin.flow.component.HasComponents, com.vaadin.flow.component.HasComponentsOfType<com.vaadin.flow.component.Component>, com.vaadin.flow.component.HasElement, com.vaadin.flow.component.HasEnabled, com.vaadin.flow.component.HasOrderedComponents, com.vaadin.flow.component.HasSize, com.vaadin.flow.component.HasStyle, com.vaadin.flow.component.HasText, ComponentMixin, ContainerMixin, JComponentMixin, Serializable
public class SJPanel extends com.vaadin.flow.component.html.Div implements JComponentMixin
Surrogate for JPanel (SD_sjpanel). Extends Vaadin Div directly (is-a) so it reaches the migrator either through :emulators.JPanel as peer, or as a richer-than-stock Vaadin container in its own right.

Why Div as peer

Bare HasComponents container — no shadow DOM (so the inline-flex / border / opaque / background CSS the inherited JComponentMixin writes lands on the host element where it actually renders), no Vaadin-specific value/selection/event behaviour to override. Same peer the existing emulator already uses.

Inherited mixin surface

Almost the entire JPanel surface comes from JComponentMixin: setLayout + CSS dispatch (recognises FlowLayout / BorderLayout, custom LayoutManagers store-but-don't- dispatch), setOpaque + lossy CSS readback, setBorder + CSS round-trip (SD_border_css_lossy), add / remove via inherited HasComponents, focus / key / ancestor / mouse / property-change / client-property surface from JComponentMixin. SJPanel itself adds only the four ctors + L&F surface + paramString tail.

Default opaque divergence

JDK JPanel installs opaque=true via L&F at construction. The mixin's setOpaque is Vaadin-first (no shadow store) and its readback is lossy CSS-based: a fresh SJPanel with no background set reports isOpaque() == false even after setOpaque(true) (no background-color CSS to read back). R_vaadin_first-accepted lossy direction; emulator-side :emulators.JPanel preserves the JDK-faithful true via field shadow per R_swing_is_truth (two-layer split, same shape SD_sjbutton takes for state-conditional icons and SD_toggle_checkbox_first_cut takes for borderPaintedFlat).
See Also:

  • Constructor Details

    • SJPanel

      public SJPanel()

    • SJPanel

      public SJPanel(boolean isDoubleBuffered)

    • SJPanel

      public SJPanel(LayoutManager layout)

    • SJPanel

      public SJPanel(LayoutManager layout, boolean isDoubleBuffered)

  • Method Details

    • getUIClassID

      public String getUIClassID()
      Swing constant for L&F lookup; PanelUI isn't pluggable here.
      Specified by:
      getUIClassID in interface JComponentMixin

    • updateUI

      public void updateUI()
      L&F swap — no-op for us; Vaadin owns the DOM.
      Specified by:
      updateUI in interface JComponentMixin

    • setUI

      public void setUI(PanelUI ui)
      L&F surgery isn't modelled; WARN so integration gaps surface. setUI's parameter type doesn't clash with Vaadin's setUI signature (no such method on Div), so the JDK-typed setter survives as a plain method.

    • paramString

      protected String paramString()
      JDK JPanel.paramString chains up and adds nothing — JPanel has no state of its own beyond what JComponent (opaque, doubleBuffered) and Container (layout=) already report. We don't model AbstractButton/JComponent paramString chains, so the tail is empty here too.

    • getAccessibleContext

      public AccessibleContext getAccessibleContext()