We Keep Coding

Extends JFrame vs. creating it inside the program

When making an application using Swing, I've seen people do one of the two things to create a JFrame. Which is a better approach and why?
I'm a beginner at Java and programming. My only source of learning is books, YouTube and Stack Overflow.
import {imports};
public class GuiApp1 {
public static void main(String[] args) {
new GuiApp1();
}
public GuiApp1() {
JFrame guiFrame = new JFrame();
guiFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
guiFrame.setTitle("Example GUI");
guiFrame.setSize(300,250);
................
}
AND
import {imports};
public class GuiApp1 extends JFrame {
public Execute() {
getContentPane().setBackground(Color.WHITE);
getContentPane().setLayout(null);
setSize(800, 600);
.............
}
public static void main(String[] args) {
Execute frame1 = new Execute();
frame1.setVisible(true);
}
}

Thoughts:
Avoid extending JFrame as it ties your GUI to being, well a JFrame. If instead you concentrate on creating JPanels instead, then you have the freedom to use these JPanels anywhere needed -- in a JFrame, or JDialog, or JApplet, or inside of another JPanel, or swapped with other JPanels via a CardLayout.
Avoid inheritance in general, especially of complex classes. This will prevent pernicious errors, such as inadvertent method overrides (try creating a JFrame or JPanel that has a getX() and getY() method to see what I mean!).
Avoid inheritance of complex classes if you are using an IDE: If you override a complex class, when you call methods on objects of these classes, you will have many, too many, choices of methods offered to you.
Encapsulation is good, is and allows for creation of safer code. Expose only that which needs to be exposed, and control that exposure as much as possible.

Prefer composition over inheritance.
The 2nd example uses inheritance, but for no good reason, since it does not change the functionality of JFrame.
As an aside, if those are examples of code you are seeing, find a new source1 supplementary. Even in the few code lines shown, each does highly questionable things. E.G.
Neither GUI is created on the Event Dispatch Thread.
getContentPane().setBackground(Color.WHITE);
getContentPane().setLayout(null);
setSize(800, 600);
The first part of the 1st line (getContentPane()) has not been necessary since Java 1.5
The second line uses a null layout, which will break in more ways I can count or describe.
The third line should best be replaced with pack();
JFrame guiFrame = new JFrame();
guiFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
guiFrame.setTitle("Example GUI");
guiFrame.setSize(300,250);
The first and 3rd lines could be contracted to: JFrame guiFrame = new JFrame("Example GUI");
The 2nd line is better set to guiFrame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
The 3rd line again sets a size to the frame.
Supplement
Having mentioned you do search SO, here is a tip. Check out the posts of the top 15 providers of answers in the Swing top users. Whatever advice/code you glean from these people, would commit few if any of the mistakes in those code samples. Some don't often (or ever) provide self contained examples like a few of us commonly do (and don't look to those examples necessarily for OO design as opposed to just technique), but whatever code they provide, or advice they give, should be highly considered.

Personally, the first approach (creating an instance of JFrame) is preferred, I prefer this because...
It doesn't lock your application into a dedicated container...you see a lot of people wanting to add applets to frames and frames to applets, if they had simple put the majority of there GUI in a JPanel to start with, they wouldn't have these issues.
It also means that the UI you create is much more flexible. For example, you can re-use it, either in the current application or future applications, you don't lock yourself in.
The main gripe I have with extending JFrame is, you're not actually adding any new features or functionality to it, which could be effectively re-used beyond using setVisible
The other issue I have with extending JFrame is people then promptly override paint, which is really, really bad. There are so many issues with doing this it's simply painful to have to repeatedly list them...
So...for more 2 cents worth. Create an instance of JFrame and add your content to it. If required, create a static method call showMyAwesomeGUI which does it for you...

The first approach is better.
Typically you are not adding any new functionality to the frame so creating a direct instance of the class makes sense.

Go for the first approach.
Because with that you can have more frames to be created. Because the application can have more than one window. As in the second case you can't create more frames.

It does not matter.
There are reasons why you might do one or the other, but absent any of those reasons it makes no difference whatsoever.
Now, if you were writing something that might operate from the command line or might be a GUI program, obviously you could want a 'main' class that was not a GUI class.
If you worked in a programming shop where one or the other was the standard, by all means follow the standard. There is no right answer to this one, and in fact very little to choose between them.

Lag before JFrame event handlers are added?

I'm working on a simple Java swing project. This is the code of the main class (name changed):
public class MainProg
{
private static MainProg program;
//mainWin is a JFrame
private MainWindow mainWin;
//Event handler class which extends MouseAdapter
private TrayManager trayMgr;
public static void main(String[] args)
{
program = new MainProg();
}
public MainProg()
{
mainWin = new MainWindow();
trayMgr = new TrayManager();
mainWin.startBtn.addMouseListener(trayMgr);
mainWin.setVisible(true);
}
}
As is clear, when the program starts, in main() it creates a new instance of the MainProg class, which then calls the constructor. In the constructor, it creates a new instance of the JFrame mainWin. It then attaches an event handler to a button on mainWin.
In the event handler class trayMgr, the only method is mouseClicked() which does nothing
except a System.out.println('Clicked');
The issue is, when I run this program in Netbeans, the JFrame is shown right away, but I seem to have to click the button 2-3 times before the message is printed in the console.
Is this just something specific to Netbeans, or do I have to change something to make the event handler be set before the window is made visible?

Your threading issue is not likely one that is causing your current problem, but there's the theoretic potential for problems, and I've seen some real problems associated with some of the more touchy look and feels. Quite simply you should queue your code that starts your GUI onto the Swing event thread. You do this by doing:
public void main(String[] args) {
SwingUtilities.invokeLater(new Runnable(
public void run() {
program = new MainProg();
}
));
}
Someone else recommended using invokeAndWait(...) instead of invokeLater(...) but this can be risky especially if you inadvertently make this call from within the Swing event thread itself. For your situation you're better off using invokeLater(...).
But again, I think the main problem with the code you have shown was inappropriate use of MouseListener where an ActionListener should have been used. Learning to code any GUI library can be quite tricky, and for that reason, you can't assume anything. Check out the tutorials and learn from the experts. Also if you are considering coding Swing for the long haul, consider ditching the NetBean's code-generation utilities and learn first to code Swing by hand. You won't regret doing this.

Since you asked, the code I posted here is a Java SSCCE on a different topic. invokeLater is a way of running computations on the EDT. (There is also invokeAndWait, which would work fine here, but under some other conditions can cause a deadlock.)
In fact this example is perhaps a bit over-conservative. Some references say you can run Swing from the main thread the call to show() or setVisible(). However I have a program that misbehaves under Java 7 when I try that.

doLayout() and ActionListener questions

I'm new to JSwing, so pardon me what might be some really beginners' questions.
After reading the tutorial on how to use top level containers, I tried the following code inside the actionPerformed event in a button:
private void colgarActionListener(java.awt.event.ActionEvent evt) {
auxButton = new JButton();
auxButton.setSize(100,30);
auxButton.setText("Me button");
getContentPane().add(auxButton);
getContentPane().doLayout();
}
As you expected, it occurs that it does not work. The button just does not appear. If I try a ridiculous thing such as:
getContentPane().setBackground(Color.red);
instead of
getContentPane().doLayout();
it works. What am I doing wrong?
And the last one: if I write a class which works as a custom ActionListener (with its constructor with parameters), where should I put it? As a private class inside the GUI code? It just feels so dirty... Or as a public class inside another package. maybe?
Thank you very much.
Regards.
Martín.

You will want to read up on how the layout managers work and how to use them for that is one of the keys to using Swing (not JSwing by the way). The Layout Manager Tutorial is a great place to start.
For one, avoid using null layout and setBounds(...) For another, contentPane's usually use BorderLayout. Also, I've never seen doLayout() used before in this way. Instead I've usually seen validate() or revalidate() followed by repaint() called on the container after changing its components.

Yes, an ActionListener is typically implemented as not only a private class, but an anonymous class, exactly at the use site. Anonymous class is when you write
x.addActionListener(new ActionListener() { public void actionPerformed(Event e) {
... stuff to do ...
}});

Java/Swing GUI best practices (from a code standpoint) [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
As a contrast to this wiki, I am looking for the proper way to implement Swing GUI controls from a coding standpoint.
I have been on a quest to learn Java and its GUI tools but I find internet tutorial after internet tutorial that throws everything in main and I know this isn't right.
I've also tried RAD systems like Netbeans and other "visual" editors but by the time I get to coding I've got a heap of code that I don't know half of what it does, so I'm intent on learning to hand code swing, and I know the basic controls and layout, but want to do it the right way.
Is there a model or standard I'm missing?
example questions...
do I extend JFrame and create my own frame object? (I would assume yes)
do I encapsulate the main menu inside that frame object? or do I create its own? etc...
How to I separate "View" logic from "Application" logic?
Basically, I'm looking for what the industry standard is, on how to organize GUI code.

Since there seems to be some argument about what constitutes "best practices", I'll give you what I have found works best for me, and my reasoning:
1.
Each window should extend either JFrame or JDialog (depending on the type of window). This makes it easy to control the properties of the window without specifying a specific object every time. This is more of the general case, though, as I have been known to do it both ways.
2.
The main() method should be in a separate class. This increases the likelihood of being able to use your window classes elsewhere, as they are not tied to specific implementations. Technically it doesn't make a difference, but application startup code just doesn't belong in a window.
3.
Listeners should be in anonymous inner classes. Your top-level class should not implement any listeners. This prevents hacks like calling the listener methods from anywhere except the object to which they are attached.
Here is a simple application with a single frame to demonstrate these practices:
public class Main {
public static void main(String[] args) {
final String text = args[0];
SwingUtilities.invokeLater(new Runnable() {
#Override
public void run() {
final MyWindow wnd = new MyWindow(text);
wnd.setVisible(true);
}
});
}
}
public class MyWindow extends JFrame {
public MyWindow(String text) {
super("My Window");
setDefaultCloseOperation(WindowConstants.DO_NOTHING_ON_CLOSE);
addWindowListener(new WindowAdapter() {
#Override
public void windowClosing(WindowEvent e) {
MyWindow.this.setVisible(false);
MyWindow.this.dispose();
}
});
final JButton btn = new JButton(text);
btn.addActionListener(new ActionListener() {
#Override
public void actionPerformed(ActionEvent e) {
JOptionPane.showMessageDialog(MyWindow.this, "Button Pressed", "Hey", JOptionPane.INFORMATION_MESSAGE);
}
});
setLayout(new FlowLayout());
add(btn);
pack();
}
}

I agree with all of Jonathan's points.
Each window should extend either JFrame or JDialog...
The main() method should be in a separate class...
Listeners should be in anonymous inner classes...
I would also like to add the following:
Use GridBagLayout (GBL) judiciously. GBL is a powerful Layout Manager, difficult to learn, but quite powerful.
Consider hand coding all your UI. I'm personally not a fan of the code that is produced by visual editors. But, with that said I have not used a visual editor in several years (2000ish). They might be better at this point.
Use JPanels judiciously. Look at your ui and determine which components should behave the same as the screen size changes and then group those components together on a JPanel. Consider using JPanels inside of JPanels to get your correct resizing behavior.
I normally take a slightly different approach on having my components handle events then Jonathan does, but I believe his approach is a bit cleaner then mine.
Also, really study the use of MVC and Layered Architecture. It is truly best not to be mixing UI and Business Logic together.

Updating the Jpanel of a class

After some advice on using jpanel - I'm new to java and playing around with the GUI elements.
Bascially what I'm curious about is if I can set up a Jpanel in one class, then somehow add labels etc to the that container, but from another class.
Is this possible ? or do i have to set the entire GUI up in one class, but then I guess I would have the same issue, if I wanted to update those fields I had set up in the main class from another class?
Apologies I don't really have any code that's usefull to demostrate here - I'm just trying to get the idea going, working out if its possible before I go ahead. And I'm not even sure if this is possible. Any advice would be greatly appreciated.
Thanks

As long as you have a reference to the JPanel, you can add whatever GUI-element you want, by calling add(JComponent comp) on the JPanel.
So, you can do something like this:
class Panel extends JPanel{
...
}
class Main{
public Main(JPanel thePanel){
thePanel.add(new JButton("Hello"));
}
}
Was this what you were looking for?
You can also update the fields added to the panel from another class, if you have a public accessor-method set up, in the class. So in your panel class, you have a method:
public JButton getButton(){
return button;
}
Then you can access the button from whatever class with a reference to your panel class, like this:
panel.getButton().setText("Some text");
Note that the button could just as well be public, then you could simply call the method directly: panel.button.setText("Some text"); but this is not considered good code, as it violates some general good OOP practices, not relevant to mention here.