Editing Swing (Java) (section)

===Foundations===
Swing is platform-independent because it is completely written in Java. Complete documentation for all Swing classes can be found in the [https://docs.oracle.com/javase/6/docs/api/ Java API Guide] for Version 6 or the [https://docs.oracle.com/javase/8/docs/api/ Java Platform Standard Edition 8 API Specification] for Version 8.

====Extensible====
Swing is a highly modular-based architecture, which allows for the "plugging" of various custom implementations of specified framework interfaces: Users can provide their own custom implementation(s) of these components to override the default implementations using Java's inheritance mechanism via {{Javadoc|module=java.desktop|package=javax.swing|class=LookAndFeel|text=LookAndFeel|monotype=y}}.

Swing is a '''component-based framework''', whose components are all ultimately derived from the {{Javadoc|module=java.desktop|package=javax.swing|class=JComponent|text=JComponent|monotype=y}} class. Swing objects asynchronously fire events, have bound properties, and respond to a documented set of methods specific to the component. Swing components are [[JavaBeans]] components, compliant with the [https://www.oracle.com/java/technologies/javase/javabeans-spec.html JavaBeans specification].

====Configurable====
Swing's heavy reliance on runtime mechanisms and indirect composition patterns allows it to respond at run time to fundamental changes in its settings. For example, a Swing-based application is capable of [[hot swapping]] its user-interface during runtime. Furthermore, users can provide their own look and feel implementation, which allows for uniform changes in the look and feel of existing Swing applications without any programmatic change to the application code.

====Lightweight UI====
Swing's high level of flexibility is reflected in its inherent ability to override the native host [[operating system]] (OS)'s GUI controls for displaying itself. Swing "paints" its controls using the Java 2D APIs, rather than calling a native user interface toolkit. Thus, a Swing component does not have a corresponding native OS GUI component, and is free to render itself in any way that is possible with the underlying graphics GUIs.

However, at its core, every Swing component relies on an [[Abstract Window Toolkit|AWT]] container, since (Swing's) {{Javadoc|module=java.desktop|package=javax.swing|class=JComponent|text=JComponent|monotype=y}} extends (AWT's) Container. This allows Swing to plug into the host OS's GUI management framework, including the crucial device/screen mappings and user interactions, such as key presses or mouse movements. Swing simply "transposes" its own (OS-agnostic) semantics over the underlying (OS-specific) components. So, for example, every Swing component paints its rendition on the graphic device in response to a call to component.paint(), which is defined in (AWT) Container. But unlike AWT components, which delegated the painting to their OS-native "heavyweight" widget, Swing components are responsible for their own rendering.

This transposition and decoupling is not merely visual, and extends to Swing's management and application of its own OS-independent semantics for events fired within its component containment hierarchies. Generally speaking, the Swing architecture delegates the task of mapping the various flavors of OS GUI semantics onto a simple, but generalized, pattern to the AWT container. Building on that generalized platform, it establishes its own rich and complex GUI semantics in the form of the {{Javadoc|module=java.desktop|package=javax.swing|class=JComponent|text=JComponent|monotype=y}} model.

====Loosely coupled and MVC====
The Swing library makes heavy use of the [[model–view–controller]] software [[design pattern (computer science)|design pattern]],<ref>{{cite web |last1=Fowler |first1=Amy |url=https://www.oracle.com/java/technologies/a-swing-architecture.html |title=A Swing Architecture Overview |publisher=[[Sun Microsystems]] |access-date=2020-07-26}}</ref> which conceptually decouples the data being viewed from the user interface controls through which it is viewed. Because of this, most Swing components have associated ''models'' (which are specified in terms of Java [[interface (computer science)|interfaces]]), and the programmers can use various default implementations or provide their own. The framework provides default implementations of model interfaces for all of its concrete components. The typical use of the Swing framework does not require the creation of custom models, as the framework provides a set of default implementations that are transparently, by default, associated with the corresponding {{Javadoc|module=java.desktop|package=javax.swing|class=JComponent|text=JComponent|monotype=y}} child class in the Swing library. In general, only complex components, such as tables, trees and sometimes lists, may require the custom model implementations around the application-specific data structures. To get a good sense of the potential that the Swing architecture makes possible, consider the hypothetical situation where custom models for tables and lists are wrappers over [[Data Access Object|DAO]] and/or [[Ejb|EJB]] services.

Typically, Swing component model objects are responsible for providing a concise interface defining events fired, and accessible properties for the (conceptual) data model for use by the associated JComponent. Given that the overall MVC pattern is a loosely coupled collaborative object relationship pattern, the model provides the programmatic means for attaching event listeners to the data model object.wat these events are model centric (ex: a "row inserted" event in a table model) and are mapped by the JComponent [[Subclass (computer science)#Subclasses and superclasses|specialization]] into a meaningful event for the GUI component.

For example, the {{Javadoc|module=java.desktop|package=javax.swing|class=JTable|text=JTable|monotype=y}} has a model called {{Javadoc|module=java.desktop|package=javax.swing.table|class=TableModel|text=TableModel|monotype=y}} that describes an interface for how a table would access tabular data. A default implementation of this operates on a two-dimensional [[Array data structure|array]].

The view component of a Swing JComponent is the object used to graphically represent the conceptual GUI control. A distinction of Swing, as a GUI framework, is in its reliance on programmatically rendered GUI controls (as opposed to the use of the native host OS's GUI controls). Prior to [[Java version history#Java SE 6|Java 6 Update 10]], this distinction was a source of complications when mixing AWT controls, which use native controls, with Swing controls in a GUI (see [[Abstract Window Toolkit#Mixing AWT and Swing components|Mixing AWT and Swing components]]).

Finally, in terms of visual composition and management, Swing favors [[Layout manager|relative layouts]] (which specify the positional relationships between components) as opposed to absolute layouts (which specify the exact location and size of components). This bias towards "fluid"' visual ordering is due to its origins in the [[Java applet|applet]] operating environment that framed the design and development of the original Java GUI toolkit. (Conceptually, this view of the layout management is quite similar to that which informs the rendering of HTML content in browsers, and addresses the same set of concerns that motivated the former.)