If swing is betters graphics handler than awt, why do we need to use awt at all?

Doesnt swing have the same capabilities as awt? Can swing also access everyhing that awt can, like java.awt.GraphicsDevice?

As I understand it, Swing is an extension that builds upon awt. It replaces some bits like the controls with better versions as well as adding a load more, but you still need to use awt classes when building a Swing GUI.

I read somewhere that is not a good idea to mix awt with swing when programming? I also read that swing is not very Thread friendly. Is there any truth to these statements?

No, that's total rubbish. It's impossible not to mix awt and Swing. Why are you worrying about this?

What's not a good idea is to mix AWT and Swing components in the same GUI. For more read Mixing heavy and light components and Mixing Heavyweight and Lightweight Components.

Thanks. I was asking cause I just wanted to learn about one package instead of both. So you guys say that I have to use awt classes while designing an interface with swing. But there are so many damn classes, how do I know off hand which package the classes are in, and what classes I would need to say put an image on a full size screen? Anyway to find out about this stuff easily, or do I need to read extensive books on java

The only classes in the java.awt.Component hierarchy tree from AWT that you should, IMHO, worry about are Component itself and Container. That actually doesn't leave out much; the only classes you can really ignore are Button (JButton), Canvas (JPanel), Checkbox (JCheckBox), Choice (JComboBox), Panel (JPanel), Applet (JApplet), Dialog (JDialog), Frame (JFrame), Label (JLabel), List (JList), Scrollbar (JScrollBar and/or JScrollPane) and TextComponent / TextArea / TextField (JTextComponent / JTextArea / JTextField). Do you notice how almost all Swing replacements have the same name but with a J in front of it?
The java.awt.MenuComponent hierarchy tree can be completely ignored, with matching equivalents in Swing. Again, the replacements simply have the same name but with the extra J.

All other classes are not components themselves, and can be used without a problem. Especially the AWT layout managers are used heavily in Swing.

FileDialog seems to have people both for and against it. Those against it say you should JFileChooser. Those for it prefer the look&feel of FileDialog. And because it's a top-level window of its own it's still allowed to be used with Swing components; there is only a problem if you put both heavy-weight (AWT) and light-weight (Swing) components in the same window.

Rob spoor and all

Thank you for your explanations.