Differencebetween Swing and Awt

What is the difference between Swing and AWT?

AWT is a Java interface to native system GUI code present in your OS. It will not work the same on every system, although it tries.

Swing is a more-or-less pure-Java GUI. It uses AWT to create an operating system window and then paints pictures of buttons, labels, text, checkboxes, etc., into that window and responds to all of your mouse-clicks, key entries, etc., deciding for itself what to do instead of letting the operating system handle it. Thus Swing is 100% portable and is the same across platforms (although it is skinnable and has a "pluggable look and feel" that can make it look more or less like how the native windows and widgets would look).

These are vastly different approaches to GUI toolkits and have a lot of consequences. A full answer to your question would try to explore all of those. :) Here are a couple:

AWT is a cross-platform interface, so even though it uses the underlying OS or native GUI toolkit for its functionality, it doesn't provide access to everything that those toolkits can do. Advanced or newer AWT widgets that might exist on one platform might not be supported on another. Features of widgets that aren't the same on every platform might not be supported, or worse, they might work differently on each platform. People used to invest lots of effort to get their AWT applications to work consistently across platforms - for instance, they may try to make calls into native code from Java.

Because AWT uses native GUI widgets, your OS knows about them and handles putting them in front of each other, etc., whereas Swing widgets are meaningless pixels within a window from your OS's point of view. Swing itself handles your widgets' layout and stacking. Mixing AWT and Swing is highly unsupported and can lead to ridiculous results, such as native buttons that obscure everything else in the dialog box in which they reside because everything else was created with Swing.

Because Swing tries to do everything possible in Java other than the very raw graphics routines provided by a native GUI window, it used to incur quite a performance penalty compared to AWT. This made Swing unfortunately slow to catch on. However, this has shrunk dramatically over the last several years due to more optimized JVMs, faster machines, and (I presume) optimization of the Swing internals. Today a Swing application can run fast enough to be serviceable or even zippy, and almost indistinguishable from an application using native widgets. Some will say it took far too long to get to this point, but most will say that it is well worth it.

Finally, you might also want to check out SWT (the GUI toolkit used for Eclipse, and an alternative to both AWT and Swing), which is somewhat of a return to the AWT idea of accessing native Widgets through Java.

What is the difference between the Java awt package, Javafx, and Java Swing

Java awt is the first generation, Java Swing is the second generation and the JavaFx is the third generation UI-Toolkit for designing and implementing Graphical User Interfaces with Java.

If you want to learn more about these APIs and the other related APIs, you did not mention, please read the discussion here and there is also a video about the differences between these three APIs here.

What's the difference between Java Swing & Java Applets

Swing is a set of platform independent UI tools (JButton, JScrollBar, etc.). It guarantees that your user interface design will look the same on different platforms. An applet is an app that runs inside a browser or other hosted environment. An applet can use Swing UI, but doesn't need to.

Personally, I wouldn't develop a game in either if it's graphics intensive. If you want lightweight, I would suggest using JavaScript in Chrome's V8. Check out Chrome's developer showcase. They're doing amazing things with Javascript these days.

AWT and Swing components not rendering properly

Don't mix Swing and AWT components. Mixing them together might (often does) cause problems due to Swing providing lightweight components, while AWT has heavyweight components.

I.E. Instead of Component, Label & TextField use JComponent (or JPanel), JLabel & JTextField.

Note: Swing is built on AWT components - the inheritance hierarchy of Swing components typically leads back to an AWT component eventually. Also Swing uses a great many AWT APIs (printing, Java2D fonts, ..) and many of the AWT based layouts. It's just the components we need to be careful with.

Swing native look and feel vs. AWT style

1. No, it is not supported
2. It's an emulation, just a Look and Feel like the others

(Java)Why some people still use the awt library and not the swing?

here are a few other advantages to Swing over AWT which I found on http://www.jguru.com/faq/view.jsp?EID=106026:

• Swing provides both additional components and added functionality to AWT-replacement components

• Swing components can change their appearance based on the current "look and feel" library that's being used. You can use the same look
  
  and feel as the platform you're on, or use a different look and feel

• Swing components follow the Model-View-Controller paradigm (MVC), and thus can provide a much more flexible UI.

• Swing provides "extras" for components, such as:

  • Icons on many components
  • Decorative borders for components
  • Tooltips for components

• Swing components are lightweight (less resource intensive than

• Swing provides built-in double buffering
• Swing provides paint debugging support for when you build your own

components

Swing also has a few disadvantages:

• It requires Java 2 or a separate JAR file

• If you're not very careful when programming, it can be slower than AWT (all components are drawn)

• Swing components that look like native components might not act exactly like native components

Moreover! habit is everything..They will do in which they have practice.But I prefer Swing but we eventually need AWT for event handling purpose or Layout

Different Output for Exactly Same Code Using Java Swing and AWT

@Override
public void paintComponent(Graphics g){
    ...
    while(q.isEmpty()==false){

        Node node = q.poll();

The problem is that you're modifying the queue inside paintComponent. The UI system can call paintComponent any time that it wants to, for example dragging another window over the panel will cause repaints.

paintComponent should therefore be stateless and not modify the queue.

If your use of poll is absolutely necessary, one simple solution is to copy the queue:

@Override
public void paintComponent(Graphics g){
    Queue<Node> q = new LinkedList<>(this.q);

Seems like you could also just iterate with a for-each loop.

---

Few other things:

• Your code in main where you create the GUI needs to be wrapped inside a call to SwingUtilities.invokeLater:

  public static void main(String[] args) {
      SwingUtilities.invokeLater(new Runnable() {
          @Override
          public void run() {
              // create the GUI here
          }
      });
  }
  

  This is because Swing is single-threaded and not thread-safe. See Initial Threads.

• You should call super.paintComponent, which paints the JPanel (background color, etc.):

  @Override
  protected void paintComponent(Graphics g) {
      super.paintComponent(g);
  

• As shown in the previous code snippet, paintComponent is a protected method and there's no reason to make it public.

• You shouldn't use setSize on a JFrame. If you want the frame to be a fixed size, you should override getPreferredSize() on the JPanel, then call pack() on the frame. The frame will size itself automatically around the panel inside it. (Example shown here.) The size of a JFrame includes e.g. title bar and borders so using setSize probably also interferes with your painting coordinates.

---

Related Topics