A look back at Java Swing

Swing is a GUI toolkit in Java. It was developed to provide a more sophisticated set of GUI components than the earlier Abstract Window Toolkit. It has been around since 1998 and used a lot in its time.

One of the things that got me into programming was the desire to make something that interacts with people. I was convinced programming isn't just reversing strings and counting primes, which was all I had seen in the name of programming back in tenth grade.

Enter Swing. It provided features like Cross-Platform Consistency (though I beg to differ), use of MVC architecture, Customizability, etc. It is part of Java Foundational Classes, embedding it in the language.

Swing is built on top of a bit-older java.awt (Abstract Window Toolkit) package, and provides lightweight components as opposed to awt. It depends on many awt imports for its functionality. Most event listeners such as MouseListener, KeyListener and ActionListener is imported from java.awt.event. Many swing components work the same as the ones in awt, the only difference being the prefix J- attached to the class names. The built-in components are highly customizable. Here's an example of a modified GradientPanel component that extends the built-in JPanel.

import javax.swing.*;
import java.awt.*;
class GradientPanel extends JPanel
    {
        static Color in=new Color(253, 180, 174),out=new Color(245, 235, 234);
        static int x,y;
        static double param;
        public GradientPanel()
        {
            super();
            new javax.swing.Timer(150,new ActionListener()
            {
                public void actionPerformed(ActionEvent e)
                {
                    x=(int)((getWidth()/2)*(1.0+Math.sin(param)));
                    y=(int)((getHeight()/2)*(1.0+Math.cos(param)));
                    param+=0.01;
                    repaint();
                }
            }).start();
        }
        //Rendering can be totally customized by overriding the paintComponent method.
        @Override
        public void paintComponent(Graphics gg)
        {
            super.paintComponent(gg);
            Graphics2D g=(Graphics2D)gg;
            g.setPaint(new RadialGradientPaint(x,y,
                    Math.max(getWidth(),getHeight()),
                    new float[]{0.33f,0.9f},
                    new Color[]{in,out}));
            g.fillRect(0,0,this.getWidth(),this.getHeight());
        }
    }

Here's what the component looks like:

Modern UI frameworks and toolkits have completely abstracted away the process of rendering the elements and handling Event Listeners. Take React for example. Its declarative syntax means we are only bothered by how we want things to appear on the screen: and not how we are implementing that appearance. Swing, on the other hand, requires you to deal with the Event Dispatch Thread, a thread that handles component paintings and events. It is the developer's job to keep the thread as clean and free, avoiding heavy computations on it.

About what I said about cross-platform consistency: It might have worked in the olden days, but after 25 years today, it is no longer a feature. I had a chess project in Swing. It rendered fine on Windows 10 and Ubuntu (with some hiccups though), but when I shifted to Windows 11, all the Chess Pieces appeared zoomed. I had to adjust their scaling, but now they would appear too small on other platforms.

I wouldn't consider someone learning Swing today to have made a well-informed decision. There are better frameworks out there- even in Java, the newer JavaFX offers impressive UI management and is much more visually pleasing than Swing.

Desktop UI frameworks are already on a decline as the focus shifts to web apps. Tools such as Electron let us simulate our website like a native desktop application, further reducing the need for a UI framework.

I learned Swing at an early point in my programming journey, and it has helped me understand the mechanics of UI rendering. I have made some pretty crappy-looking apps with it, but I appreciate what I learned from it. I rarely use it nowadays, and if you are adamant you want to learn a desktop GUI framework in Java only, you could go for JavaFX.