what is the difference between light-wieght and Heavy-weightcomponent?

[john]

some one have told me that swing is light-wieght component and it was
written by pure java code, l am a little puzzled that how does swing
implements component related funciton with pure java code?

 

[Joshua Cranmer]

some one have told me that swing is light-wieght component and it was
written by pure java code, l am a little puzzled that how does swing
implements component related funciton with pure java code?

It's not totally pure Java code, in that the graphics APIs do eventually
hit native code.

But, in essence, it means that the native OS is merely told that there's
a giant blank canvas where the Java window exists and the Swing APIs
paint stuff on that canvas. AWT, by contrast, tells the native OS that
there exists a list box in such-and-such a location, a textbox in
another location, etc.

 

[Roedy Green]

some one have told me that swing is light-wieght component and it was
written by pure java code, l am a little puzzled that how does swing
implements component related funciton with pure java code?

see http://mindprod.com/jgloss/heavyweight.html

http://mindprod.com/jgloss/lightweight.html
--
Roedy Green Canadian Mind Products
http://mindprod.com

"Don’t worry about where you are. Watch the first derivative."
translation:
"Don’t worry about how things are. Watch where they are headed."
~ Fred Green (born: 1913-07-12 died: 1992-04-10 at age: 78) (my Dad, an electrical engineer)

 

[Arne Vajhøj]

some one have told me that swing is light-wieght component and it was
written by pure java code, l am a little puzzled that how does swing
implements component related funciton with pure java code?

Theoretically:
lightweight = simple & small footprint
heavyweight = complex % big footprint

Reality:
lightweight = what I want to sell you
heavyweight = what the competition want to sell you or what I wanted
to sell you 3 years ago

Swing obviously calls native code for the final output (I believe that
it calls some low level AWT classs & methods that calls native code).
But it has more logic in the Java code than AWT.

When applying the above mentioned rule, then AWT became heavy and
Swing became light.

It is not my experience that Swing apps are light in memory footprint.

Arne

 

[Lew]

Theoretically:
lightweight = simple & small footprint
heavyweight = complex % big footprint

Reality:
lightweight = what I want to sell you
heavyweight = what the competition want to sell you or what I wanted
to sell you 3 years ago

Swing obviously calls native code for the final output (I believe that
it calls some low level AWT classs & methods that calls native code).
But it has more logic in the Java code than AWT.

When applying the above mentioned rule, then AWT became heavy and
Swing became light.

It is not my experience that Swing apps are light in memory footprint.

The reference to "heavyweight" and "lightweight" in the AWT/Swing world is not
about footprint but the use of native widgets. AWT components are proxies to
native components, and it's this partnership with a native component that is
the "heavy" weight. Swing components are implemented completely as Java
calls, with only the actual graphics drawing going to native calls. This
makes lighter demands on the native graphics infrastructure, thus it's
"lightweight". Presumably this would allow for some nifty Swing performance
optimizations, as succeeding generations of Java supposedly have done.

 

[Arne Vajhøj]

The reference to "heavyweight" and "lightweight" in the AWT/Swing world
is not about footprint but the use of native widgets. AWT components
are proxies to native components, and it's this partnership with a
native component that is the "heavy" weight. Swing components are
implemented completely as Java calls, with only the actual graphics
drawing going to native calls. This makes lighter demands on the native
graphics infrastructure, thus it's "lightweight". Presumably this would
allow for some nifty Swing performance optimizations, as succeeding
generations of Java supposedly have done.

I still suspect that it fell into the "Reality" category above.

Swing chose much Java on top of simple native controls to
get good performance.

SWT chose less Java on top of complex native controls to
get good performance.

Arne

 

[Arne Vajhøj]

I think you're mistaken about the goal. Swing chose to use lightweight
controls so that applications would look the same on all the different
platforms, not for performance reasons.

Ah. That makes sense.

Note that I do not have a problem with "Swing uses lightweight
controls" - that is easy to argue.

My point is with "Swing is lightweight" - that seems mostly
to be marketing BS.

This is actually true. When SWT was written Swing was horribly slow.
This isn't the case anymore and I really don't know why anyone would
choose SWT for new applications.

To get a more native look and feel ?

Arne