JavaBeans are reusable software components for Java.

They are classes that

encapsulate many objects into a single object (the bean). They are serializable, have a
0argument constructor, an! allow access to properties using getter an! setter
metho!s."!vantages#e!it$
The properties, events, an! metho!s of a bean that are e%pose! to another application
can be controlle!.
" bean may register to receive events from other objects an! can generate events that
are sent to those other objects.
"u%iliary software can be provi!e! to help configure a java bean.
The configuration setting of bean can be save! in a persistent storage an! restore! at a
later time.
&isa!vantages#e!it$
" class with a nullary constructor is subject to being instantiate! in an invali! state. 'f
such a class is instantiate! manually by a !eveloper (rather than automatically by some
(in! of framewor(), the !eveloper might not realize that the class has been improperly
instantiate!. The compiler can)t !etect such a problem, an! even if it)s !ocumente!,
there)s no guarantee that the !eveloper will see the !ocumentation.
*aving to create a getter for every property an! a setter for many, most, or all of them
can lea! to an immense +uantity of boilerplate co!e.
JavaBeans ",'#e!it$
The JavaBeans functionality is provi!e! by a set of classes an! interfaces in the
java.beans pac(age.
'nterface &escription
"pplet'nitializer -etho!s in this interface are use! to initialize Beans that are also
applets.
Bean'nfos This interface allows the !esigner to specify information about the events,
metho!s an! properties of a Bean.
.ustomizer This interface allows the !esigner to provi!e a graphical user interface
through which a bean may be configure!.
&esign-o!e -etho!s in this interface !etermine if a bean is e%ecuting in !esign mo!e.
/%ception0istener " metho! in this interface is invo(e! when an e%ception has
occurre!.
,roperty.hange0istener " metho! in this interface is invo(e! when a boun!
property is change!.
,roperty/!itor 1bjects that implement this interface allow the !esigner to change an!
!isplay property values.
2etoable.hange0istener " metho! in this interface is invo(e! when a .onstraine!
property is change!.
2isibility -etho!s in this interface allow a bean to e%ecute in environments where
the 34' is not available.
JavaBean conventions#e!it$
'n or!er to function as a JavaBean class, an object class must obey certain conventions
about metho! naming, construction, an! behaviour. These conventions ma(e it possible
to have tools that can use, reuse, replace, an! connect JavaBeans.
The re+uire! conventions are as follows5
The class must have a public !efault constructor (with no arguments). This allows easy
instantiation within e!iting an! activation framewor(s.
The class properties must be accessible using get, set, is (can be use! for boolean
properties instea! of get), an! other metho!s (socalle! accessor metho!s an! mutator
metho!s) accor!ing to a stan!ar! naming convention. This allows easy automate!
inspection an! up!ating of bean state within framewor(s, many of which inclu!e custom
e!itors for various types of properties. 6etters can have one or more than one argument.
The class shoul! be serializable. #This allows applications an! framewor(s to reliably
save, store, an! restore the bean7s state in a manner in!epen!ent of the 2- an! of the
platform.$
6wing is the primary Java 34' wi!get tool(it. 't is part of 1racle7s Java 8oun!ation
.lasses (J8.) 9 an ",' for provi!ing a graphical user interface (34') for Java
programs.
6wing was !evelope! to provi!e a more sophisticate! set of 34' components than the
earlier "bstract :in!ow Tool(it (":T). 6wing provi!es a native loo( an! feel that
emulates the loo( an! feel of several platforms, an! also supports a pluggable loo( an!
feel that allows applications to have a loo( an! feel unrelate! to the un!erlying platform.
't has more powerful an! fle%ible components than ":T. 'n a!!ition to familiar
components such as buttons, chec( bo%es an! labels, 6wing provi!es several a!vance!
components such as tabbe! panel, scroll panes, trees, tables, an! lists.
4nli(e ":T components, 6wing components are not implemente! by platformspecific
co!e. 'nstea! they are written entirely in Java an! therefore are platformin!epen!ent.
The term ;lightweight; is use! to !escribe such an element.#<$
The 'nternet 8oun!ation .lasses ('8.) were a graphics library for Java originally
!evelope! by =etscape .ommunications .orporation an! first release! on &ecember
<>, <??>. 1n "pril @, <??A, 6un -icrosystems an! =etscape .ommunications
.orporation announce! their intention to incorporate '8. with other technologies to form
the Java 8oun!ation .lasses.#@$ The ;Java 8oun!ation .lasses; were later rename!
;6wing.;
6wing intro!uce! a mechanism that allowe! the loo( an! feel of every component in an
application to be altere! without ma(ing substantial changes to the application co!e. The
intro!uction of support for a pluggable loo( an! feel allows 6wing components to
emulate the appearance of native components while still retaining the benefits of
platform in!epen!ence. 1riginally !istribute! as a separately !ownloa!able library,
6wing has been inclu!e! as part of the Java 6tan!ar! /!ition since release <.@.#B$ The
6wing classes an! components are containe! in the java%.swing pac(age
hierarchy.6wing is a platformin!epen!ent, -o!el2iew.ontroller 34' framewor( for
Java, which follows a singlethrea!e! programming mo!el.#C$ "!!itionally, this
framewor( provi!es a layer of abstraction between the co!e structure an! graphic
presentation of a 6wingbase! 34'.
8oun!ations#e!it$
6wing is platformin!epen!ent because it is completely written in Java. .omplete
!ocumentation for all 6wing classes can be foun! in the Java ",' 3ui!e.
/%tensible#e!it$
6wing is a highly mo!ularbase! architecture, which allows for the ;plugging; of various
custom implementations of specifie! framewor( interfaces5 4sers can provi!e their own
custom implementation(s) of these components to overri!e the !efault implementations
using Java7s inheritance mechanism.#D$
6wing is a componentbase! framewor(, whose components are all ultimately !erive!
from the java%.swing.J.omponent class. 6wing objects asynchronously fire events, have
boun! properties, an! respon! to a !ocumente! set of metho!s specific to the
component. 6wing components are Java Beans components, compliant with the Java
Beans .omponent "rchitecture specifications.
.ustomizable#e!it$
3iven the programmatic ren!ering mo!el of the 6wing framewor(, fine control over the
!etails of ren!ering of a component is possible. "s a general pattern, the visual
representation of a 6wing component is a composition of a stan!ar! set of elements,
such as a bor!er, inset, !ecorations, an! other properties. Typically, users will
programmatically customize a stan!ar! 6wing component (such as a JTable) by
assigning specific bor!ers, colors, bac(groun!s, opacities, etc. The core component will
then use these properties to ren!er itself. *owever, it is also completely possible to
create uni+ue 34' controls with highly customize! visual representation.
.onfigurable#e!it$
6wing7s heavy reliance on runtime mechanisms an! in!irect composition patterns allows
it to respon! at run time to fun!amental changes in its settings. 8or e%ample, a 6wing
base! application is capable of hot swapping its userinterface !uring runtime.
8urthermore, users can provi!e their own loo( an! feel implementation, which allows for
uniform changes in the loo( an! feel of e%isting 6wing applications without any
programmatic change to the application co!e.
0ightweight 4'
6wing7s high level of fle%ibility is reflecte! in its inherent ability to overri!e the native host
operating system (16)7s 34' controls for !isplaying itself. 6wing ;paints; its controls
using the Java @& ",'s, rather than calling a native user interface tool(it. Thus, a 6wing
component !oes not have a correspon!ing native 16 34' component, an! is free to
ren!er itself in any way that is possible with the un!erlying graphics 34's.
*owever, at its core, every 6wing component relies on an ":T container, since
(6wing7s) J.omponent e%ten!s (":T7s) .ontainer. This allows 6wing to plug into the
host 167s 34' management framewor(, inclu!ing the crucial !eviceEscreen mappings
an! user interactions, such as (ey presses or mouse movements. 6wing simply
;transposes; its own (16agnostic) semantics over the un!erlying (16specific)
components. 6o, for e%ample, every 6wing component paints its ren!ition on the graphic
!evice in response to a call to component.paint(), which is !efine! in (":T) .ontainer.
But unli(e ":T components, which !elegate! the painting to their 16native
;heavyweight; wi!get, 6wing components are responsible for their own ren!ering.
This transposition an! !ecoupling is not merely visual, an! e%ten!s to 6wing7s
management an! application of its own 16in!epen!ent semantics for events fire!
within its component containment hierarchies. 3enerally spea(ing, the 6wing
architecture !elegates the tas( of mapping the various flavors of 16 34' semantics onto
a simple, but generalize!, pattern to the ":T container. Buil!ing on that generalize!
platform, it establishes its own rich an! comple% 34' semantics in the form of the
J.omponent mo!el.
0oosely couple! an! -2.#e!it$
The 6wing library ma(es heavy use of the -o!elE2iewE.ontroller software !esign
pattern,#>$ which conceptually !ecouples the !ata being viewe! from the user interface
controls through which it is viewe!. Because of this, most 6wing components have
associate! mo!els (which are specifie! in terms of Java interfaces), an! the
programmers can use various !efault implementations or provi!e their own. The
framewor( provi!es !efault implementations of mo!el interfaces for all of its concrete
components. The typical use of the 6wing framewor( !oes not re+uire the creation of
custom mo!els, as the framewor( provi!es a set of !efault implementations that are
transparently, by !efault, associate! with the correspon!ing J.omponent chil! class in
the 6wing library. 'n general, only comple% components, such as tables, trees an!
sometimes lists, may re+uire the custom mo!el implementations aroun! the application
specific !ata structures. To get a goo! sense of the potential that the 6wing architecture
ma(es possible, consi!er the hypothetical situation where custom mo!els for tables an!
lists are wrappers over &"1 an!Eor /JB services.
Typically, 6wing component mo!el objects are responsible for provi!ing a concise
interface !efining events fire!, an! accessible properties for the (conceptual) !ata mo!el
for use by the associate! J.omponent. 3iven that the overall -2. pattern is a loosely
couple! collaborative object relationship pattern, the mo!el provi!es the programmatic
means for attaching event listeners to the !ata mo!el object. Typically, these events are
mo!el centric (e%5 a ;row inserte!; event in a table mo!el) an! are mappe! by the
J.omponent specialization into a meaningful event for the 34' component.
8or e%ample, the JTable has a mo!el calle! Table-o!el that !escribes an interface for
how a table woul! access tabular !ata. " !efault implementation of this operates on a
two!imensional array.
The view component of a 6wing J.omponent is the object use! to graphically represent
the conceptual 34' control. " !istinction of 6wing, as a 34' framewor(, is in its reliance
on programmatically ren!ere! 34' controls (as oppose! to the use of the native host
167s 34' controls). ,rior to Java > 4p!ate <0, this !istinction was a source of
complications when mi%ing ":T controls, which use native controls, with 6wing controls
in a 34' (see -i%ing ":T an! 6wing components).
8inally, in terms of visual composition an! management, 6wing favors relative layouts
(which specify the positional relationships between components) as oppose! to absolute
layouts (which specify the e%act location an! size of components). This bias towar!s
;flui!;7 visual or!ering is !ue to its origins in the applet operating environment that
frame! the !esign an! !evelopment of the original Java 34' tool(it. (.onceptually, this
view of the layout management is +uite similar to that which informs the ren!ering of
*T-0 content in browsers, an! a!!resses the same set of concerns that motivate! the
former.)
Felationship to ":T#e!it$
":T an! 6wing class hierarchy
6ince early versions of Java, a portion of the "bstract :in!ow Tool(it (":T) has
provi!e! platformin!epen!ent ",'s for user interface components. 'n ":T, each
component is ren!ere! an! controlle! by a native peer component specific to the
un!erlying win!owing system.
By contrast, 6wing components are often !escribe! as lightweight because they !o not
re+uire allocation of native resources in the operating system7s win!owing tool(it. The
":T components are referre! to as heavyweight components.#accor!ing to whomG$
-uch of the 6wing ",' is generally a complementary e%tension of the ":T rather than a
!irect replacement. 'n fact, every 6wing lightweight interface ultimately e%ists within an
":T heavyweight component because all of the toplevel components in 6wing
(J"pplet, J&ialog, J8rame, an! J:in!ow) e%ten! an ":T toplevel container. ,rior to
Java > 4p!ate <0, the use of both lightweight an! heavyweight components within the
same win!ow was generally !iscourage! !ue to Hor!er incompatibilities. *owever, later
versions of Java have fi%e! these issues, an! both 6wing an! ":T components can
now be use! in one 34' without Hor!er issues.
The core ren!ering functionality use! by 6wing to !raw its lightweight components is
provi!e! by Java @&, another part of J8..