m_onkey_boy
asked on
Mixing Swing with AWT... why not?
I have read in this forum that it is bad to mix Swing with AWT, but I don't understand why. I have read that Swing uses 'heavyweight' components while AWT uses 'lightweight' components, but I don't understand what that means.
What is a 'heavyweight' component and what is a 'lightweiget' component?
Since all the Swing classes extend AWT classes, if AWT classes are 'heavyweight', how can the subclasses be 'lightweight'? When you cast a Swing class to its AWT superclass, you lose functionality, so how is the Swing class 'lighter'?
And since the Swing classes extend AWT classes, you can say that a Swing class IS an AWT class.
Are there any other reasons to not mix them? I've done it and it seems to work just fine.
What do I buy by limiting my component selection to one group or the other?
What is a 'heavyweight' component and what is a 'lightweiget' component?
Since all the Swing classes extend AWT classes, if AWT classes are 'heavyweight', how can the subclasses be 'lightweight'? When you cast a Swing class to its AWT superclass, you lose functionality, so how is the Swing class 'lighter'?
And since the Swing classes extend AWT classes, you can say that a Swing class IS an AWT class.
Are there any other reasons to not mix them? I've done it and it seems to work just fine.
What do I buy by limiting my component selection to one group or the other?
.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The way I understand it (I don't know if I am correct but I 'think' that it sounds good....) is that the awt methods were not truely platform independant. They use the platform methods/objects to create the gui objects. This resulted in different appearance on different systems. My guess is that the heavy term is from using the system resources to build the objects. The OSs have a lot of backward compatable code and other junk. (a little weak there, but somewhere along those lines...ya thats it!)
The swing components extend the awt classes. Extending a class allows for some code reuse and also brings in new capabilties. It is the second part that makes the difference here. For I believe that the swing components have greater access to the VM defined methods for creating a gui object and do not rely so HEAVILY on the current system that they are running on. So, they are lighter.
I also read (a while back and I don't remember where) that the awt classes were not 'truely' system/platform independant.
Tom
The swing components extend the awt classes. Extending a class allows for some code reuse and also brings in new capabilties. It is the second part that makes the difference here. For I believe that the swing components have greater access to the VM defined methods for creating a gui object and do not rely so HEAVILY on the current system that they are running on. So, they are lighter.
I also read (a while back and I don't remember where) that the awt classes were not 'truely' system/platform independant.
Tom
Right both are portable to all systems that fully implement the JVM spec.
The AWT classes merely invoke native gui components
The swing classes draw themselfs onto a low level native panel.
Thus a button in AWT is a native system button whereas in Swing it is a native low level panel with a button drawn on it by the class.
It is advisable not to mix Swing and AWT components because AWT component are heavyweight as described above. That means that AWT components will appear 'on top of' swing components when they compete for space.
Although it is true that Swing components does inhereit from AWT components ALL swing components override the drawing of themselves. Thus the contructs of their AWT superclasses are just used as pure data containers. It also had/has the benefit of ensuring that migration is relatively painless.
The AWT classes merely invoke native gui components
The swing classes draw themselfs onto a low level native panel.
Thus a button in AWT is a native system button whereas in Swing it is a native low level panel with a button drawn on it by the class.
It is advisable not to mix Swing and AWT components because AWT component are heavyweight as described above. That means that AWT components will appear 'on top of' swing components when they compete for space.
Although it is true that Swing components does inhereit from AWT components ALL swing components override the drawing of themselves. Thus the contructs of their AWT superclasses are just used as pure data containers. It also had/has the benefit of ensuring that migration is relatively painless.
ASKER
This answer didn't bring anything that was not already provided in objects' link.
ASKER
Thank you.
I took from the article that an all-swing app is better than an all-awt app. Also, if you are building an AWT app, adding a Swing component is a lot less risky than adding an AWT component to a Swing app.
I haven't done any gui work other than for fun every now and then, so I appreciate the info.
I took from the article that an all-swing app is better than an all-awt app. Also, if you are building an AWT app, adding a Swing component is a lot less risky than adding an AWT component to a Swing app.
I haven't done any gui work other than for fun every now and then, so I appreciate the info.