The purpose of this tutorial is to introduce GUI Programming in Java, as well as discuss how to develop GUI components in Java. Far too often, beginners jump into GUI Programming without a solid background in Object-Oriented Programming and get bogged down with the bulkiness of the Swing API. This leads to procedural and bulky code.

The first strategy when working with Swing is to keep things simple. There are a bunch of different JComponents in Swing, and many in AWT. Pick only those needed, and understand their basic purposes. Yes- they have many methods inherited from parent classes. However, think back to abstraction and encapsulation. It isn't important to understand the inner workings of each JComponent, only how to work with them as needed. In other words, don't get bogged down with the thousand methods the JFrame class has. Only worry about the five or six you actually need to work with.

The second strategy is to use inheritance where appropriate. Extending certain GUI Components allows for cleaner organization of code. Let's take a look at a less OO use of GUI Components to create a simple JFrame:

On a first glance, this isn't too ugly. However, it presents some problems. First, we don't have direct access to the JFrame. So what happens when we want to hide this JFrame based on the results of another JFrame? Yes, getter and setter methods can be used. However, inheritance is useful here to provide direct access to the JFrame without use of an Object to act as a middle man. Let's look at the refactored code:

The other case I want to make for inheritance is for clean organization of the code base. A common mistake made when developing GUIs is to customize multiple Components significantly in one class. This leaves a single class of significant length that is difficult to maintain. Creating methods to create these Components and initialize them is a common way to organize them. A rule of thumb is that if a Component warrants its own method to initialize it, then it warrants its own class.

The benefit of this is twofold. First, it makes it easier to find the code for the specific Component when modifying it. The second is that it reduces the amount of code used in the other GUI classes. Consider the following class:

At a glance, this code doesn't look too troublesome to work with. As this JFrame continues to be developed, it gets more difficult to cleanly add on to each JPanel for the BorderLayout regions. While the JPanels can be compartmentalized better in the class with helper methods to initialize them, the helper methods themselves can grow quite bulky. For this reason, it is better to create subclasses for the JPanels if they will contain more than a small handful of JComponents. While a few JComponents on each JPanel isn't a pain to maintain, having a bunch of JComponents, listener code, and possibly custom painting creates a code-base more warranted for its own class. Plus, it makes each JPanel more modular and reusable.

Conclusion- This tutorial is far from comprehensive, as the Java GUI is far too bulky for any single tutorial. It also does not thoroughly cover the GUI Components used, as many other tutorials do. However, this tutorial should be used when learning GUI Programming to help when organizing one's code so as not to get overwhelmed by the Swing API.

Replies To: How to Approach Swing for Beginners

Interestingly, I find your first example cleaner and more OO than the refactored alternative you provide. Sure, the first example needs a getter (not a setter) but by using inheritance you are breaking encapsulation. The biggest problem I find by breaking encapsulation in this way is in lumping together all the methods from the JFrame class (and its parents) with your new methods. This can make it more difficult to use IDEs with auto-suggestion but more insidious is the possibility of mixing up concepts. For example, you might have another concept of height and width. There is a chance you will accidentally override the getters and setters from the parent, and there is the chance a user of the class will call the wrong method if you name it differently.

I'll concede that if you are designing a new component then you should extend an existing one. The line between designing a new component and using existing components is not a clear cut one. JScrollPane, for example, uses scrollbars and a viewport to achieve its functionality. In that sense, it just uses existing components but it also makes conceptual sense to consider it a new component in its own right. Making a main application form seems to me to lie clearly on the "using components" (i.e. "has a") side of the line.

However, I know that the rest of the Java community disagrees with me so maybe I have missed something.

For example, you might have another concept of height and width. There is a chance you will accidentally override the getters and setters from the parent, and there is the chance a user of the class will call the wrong method if you name it differently.

A lot of this is redundant though. Why implement width and height separately if the Component already supports it? True, there is the danger of inadvertently overriding an existing API method. However, once one develops a certain familiarity with Swing, it becomes fairly intuitive to determine if the Component has that method already. Plus there is the documentation to check against; and by this point, most people have graduated to IDEs where there is some notification when overriding a method. I also don't think that we should program in fear of people overriding methods. If someone is working with a class I wrote, and they didn't read the documentation, then that's their problem if they accidentally override a method.

I'd also argue that we're not violating encapsulation, since we have neither seen nor are reinventing the existing API methods, only using them.

I am going to say that in production code, I would prefer not to extend JFrame unless I have functionality to add to it. Composition vs inheritance. As for one jframe responding to a change in another to hide itself, that sounds like a job for the observer pattern. Maybe I am wrong.

I am going to say that in production code, I would prefer not to extend JFrame unless I have functionality to add to it. Composition vs inheritance.

This is my argument, though not necessarily limited to functionality. The inheritance model makes it easier to organize which Components belong to the JFrame. Whereas if the JFrame has multiple JPanels it contains, and those JPanels have other Components, it can get cumbersome to maintain. Inheritance provides a clean way to encapsulate and organize these Components, without bloating a single class with helper methods to initialize each JPanel.

For a different concept of height and width. The height and width represent the pixel size of the component, and they are subject to being changed by the LayoutManager of the container. If you have another kind of height and width (and admittedly, I'm struggling to come up with a good example) like maybe the size of an area in kilometres that has to be rescaled to fit then you run the risk of a collision.

Have you read Effective Java? The author makes a compelling case for composition over inheritance. I don't see why this shouldn't be the case for user interfaces too.

I thoroughly recommend it! It's a bit long in the tooth, and some chapters are out of date but most of the book is still relevant.

I agree I can't think of a good example for the width and height thing. But the general principle is of putting too much in the same scope. It just gets increasingly complicated for the programmer to keep tabs on.

Then there is the fact that the entire Java world does things your way, not mine.

The purpose of this tutorial is to introduce GUI Programming in Java, as well as discuss how to develop GUI components in Java. Far too often, beginners jump into GUI Programming without a solid background in Object-Oriented Programming and get bogged down with the bulkiness of the Swing API. This leads to procedural and bulky code.

The first strategy when working with Swing is to keep things simple. There are a bunch of different JComponents in Swing, and many in AWT. Pick only those needed, and understand their basic purposes. Yes- they have many methods inherited from parent classes. However, think back to abstraction and encapsulation. It isn't important to understand the inner workings of each JComponent, only how to work with them as needed. In other words, don't get bogged down with the thousand methods the JFrame class has. Only worry about the five or six you actually need to work with.

The second strategy is to use inheritance where appropriate. Extending certain GUI Components allows for cleaner organization of code. Let's take a look at a less OO use of GUI Components to create a simple JFrame:

On a first glance, this isn't too ugly. However, it presents some problems. First, we don't have direct access to the JFrame. So what happens when we want to hide this JFrame based on the results of another JFrame? Yes, getter and setter methods can be used. However, inheritance is useful here to provide direct access to the JFrame without use of an Object to act as a middle man. Let's look at the refactored code:

The other case I want to make for inheritance is for clean organization of the code base. A common mistake made when developing GUIs is to customize multiple Components significantly in one class. This leaves a single class of significant length that is difficult to maintain. Creating methods to create these Components and initialize them is a common way to organize them. A rule of thumb is that if a Component warrants its own method to initialize it, then it warrants its own class.

The benefit of this is twofold. First, it makes it easier to find the code for the specific Component when modifying it. The second is that it reduces the amount of code used in the other GUI classes. Consider the following class:

At a glance, this code doesn't look too troublesome to work with. As this JFrame continues to be developed, it gets more difficult to cleanly add on to each JPanel for the BorderLayout regions. While the JPanels can be compartmentalized better in the class with helper methods to initialize them, the helper methods themselves can grow quite bulky. For this reason, it is better to create subclasses for the JPanels if they will contain more than a small handful of JComponents. While a few JComponents on each JPanel isn't a pain to maintain, having a bunch of JComponents, listener code, and possibly custom painting creates a code-base more warranted for its own class. Plus, it makes each JPanel more modular and reusable.

Conclusion- This tutorial is far from comprehensive, as the Java GUI is far too bulky for any single tutorial. It also does not thoroughly cover the GUI Components used, as many other tutorials do. However, this tutorial should be used when learning GUI Programming to help when organizing one's code so as not to get overwhelmed by the Swing API.

This is a great tutorial. It does give me ideas to make my class work look neater. The simple codes are boring to me and I like a challenge.
Thanks!