Here is a basic program I compiled
and tried to run.

import javax.swing.*;

import java.awt.*;

public class GUITest extends Frame{
  public GUITest(){
    super("A basic GUI");
    JPanel panel = new JPanel();
    panel.setLayout(new GridLayout(2,2));
    setVisible(true);
  }

  public static void main(String [] args){
    new GUITest();
  }
}

When I run it, the window is there but it quickly stops responding and I have to forcibly quit it. I started getting this problem after I tried running the exact same program on Eclipse.

I noticed that the icon of the window in the upper-leftmost corner is not a coffee mug as I would normally expect, rather its a blank window. How can I fix this?

Sorry- I forgot to include a picture in my previous post.

Attachments screen.png 113.83 KB

Sorry- I forgot to include a picture in my previous post.

I ran it and I got the Java mug and the window, so not sure what's up there. Regarding the fact that you have to forcibly close it, I've never worked with Frames much, and I don't see a setDefaultCloseOperation function, so I changed your code to JFrame and added line 12. Again, i don't know why you didn't get the coffee mug. I did.

import javax.swing.*;
import java.awt.*;



public class GUITest extends JFrame{
  public GUITest(){
    super("A basic GUI");
    JPanel panel = new JPanel();
    panel.setLayout(new GridLayout(2,2));
    setVisible(true);
    this.setDefaultCloseOperation (JFrame.EXIT_ON_CLOSE);
  }

  public static void main(String [] args){
    new GUITest();
  }
}

I ran it and I got the Java mug and the window, so not sure what's up there. Regarding the fact that you have to forcibly close it, I've never worked with Frames much, and I don't see a setDefaultCloseOperation function, so I changed your code to JFrame and added line 12. Again, i don't know why you didn't get the coffee mug. I did.

import javax.swing.*;
import java.awt.*;



public class GUITest extends JFrame{
  public GUITest(){
    super("A basic GUI");
    JPanel panel = new JPanel();
    panel.setLayout(new GridLayout(2,2));
    setVisible(true);
    this.setDefaultCloseOperation (JFrame.EXIT_ON_CLOSE);
  }

  public static void main(String [] args){
    new GUITest();
  }
}

I tried using JFrame. Same problem still: the window stops responding and basically crashes. I get this problem with anyI Java GUI that I try to run. Before, I tried running these programs with eclipse sdk, it was working perfectly. So it was something I did on eclipse which caused these problems. I

So it works in Eclipse, but not when you use a text editor and the command prompt? Or is that vice versa? Possibly you have more than one JRE? Try typing the FULL path of the java and javac programs in your command line when you type the command in the command line. What works in Eclipse should work in Command Line and vice versa. The only differences, I think, would be the paths and classpaths.

So it works in Eclipse, but not when you use a text editor and the command prompt? Or is that vice versa? Possibly you have more than one JRE? Try typing the FULL path of the java and javac programs in your command line when you type the command in the command line. What works in Eclipse should work in Command Line and vice versa. The only differences, I think, would be the paths and classpaths.

It works in neither eclipse nor when I use a command line.

Initially, it worked when I used the command line and text editor. Then I installed Eclipse, created a new workspace, new project, imported the java files into a new package and tried running it. This is when the problem began.

Now absolutely _any_ Java program (with a GUI) that I try to run at all ,whether by using a command prompt or Eclipse, ends up crashing. There is also the absence of the coffee mug, as I mentioned earlier.

Are you using the Sun version of Java? Because I'm pretty sure that there are over versions floating around (for whatever reason). Also, what Version number are you using? I believe 1.6.0_14 is the latest JDK version....

also, The error means that (for whatever reason...) you need the following line inside your class:

static final long serialVersionUID = 5119206910101689152L;

But that's only for Serialized objects.... Hmm.... Your class is not Serialized....

...And I think it's safe to ignore the warning about Serializable unless your class implements Serializable, which it does not.

Your class inherits from Frame or JFrame, both of which are declared as "implements Serializable", so that's why your class is seen by the compiler as implementing serializable as well. The serialVersionUID thing is intended to provide some insurance against changes in the way these classes are serialized (you will see the warnings about serialized versions not necessarily being compatible with future releases all over the API doc)- you supposedly can check the version and thus deserialize accordingly - in theory.
It's actually quite annoying, and completely useless unless you expect to serialize/deserialize across different versions of the classes. Fortunately Eclipse will stick one in for you as a "quick fix".

1. The SerialUID thingie

You can make this go away permanently if you go into eclipse-preferences->java->compiler->errors/warnings and change "Serializable class without serialVersionUID" to Ignore. It's not a good idea to get used to creating a serialUID without knowing why it's there in the first place. May cause you a bunch of trouble when you first start serializing objects :P

2. EDT - Event Dispatch Thread
All GUI code in java, i.e. code that manipulates GUI-widgets in any way, must run on the EDT. In previous versions of java it was allowed to manipulate GUI-widgets off the EDT if the widgets wasn't realized yet - i.e visible. In the newest versions of java, you _have_ to run all GUI-code on the EDT. How? Simple. Use SwingUtilities.invokeLater(Runnable).

Something like this:

import javax.swing.*;
import java.awt.*;
 
 
 
public class GUITest extends JFrame{
  public GUITest(){
    super("A basic GUI");
    JPanel panel = new JPanel();
    panel.setLayout(new GridLayout(2,2));
    setVisible(true);
    this.setDefaultCloseOperation (JFrame.EXIT_ON_CLOSE);
 }
 
  public static void main(String [] args){
    SwingUtilities.invokeLater(new Runnable() {
      public void run() {
        new GUITest();
      }
    });
  }
}

Also - any reason why you have included a JPanel in the code? It doesn't do anything, since it's not added to the JFrame's contentPane.

And, I would just like to insert some personal opinions about GUI programming since you're new to the stuff. I never subclass a JFrame to create an application. I have a class that instantiates a JFrame and populates it with its content. After all, do you subclass a ArrayList every time you use one? You only need to extend a class if you want to change how it works - i.e. override methods or add new methods. For anything else - use composition over inheritance. I know that the Sun tutorials always extends JFrame and JPanel and such, but quite frankly - the Sun tutorials are not good at all, other than to show how widgets work. They do not show good programming techniques, or real life use of the widgets (most of the time).

I disagree. The Sun tutorials are quite good. The reason they extend JFrame a lot of the time is because your code is an implementation of the JFrame class's functionality. But whether or not you subclass JFrame is largely irrelevant - it can be done either way and doesn't really impact your design negatively either way. But anyway, the Sun tutorials are extremely good, they give a very good and detailed foundation to begin doing some serious work with Swing. You're the first person I've ever heard of complaining about those tutorials... btw, do you use SWT? In Swing they are called Components not widgets...

Does anyone understand why the program that I wrote in post 3 does not work for the OP, whether in Eclipse or by text editor and command line? It ran fine for me, but not for the OP, and it seems to me that the OP should definitely not be getting the results he is getting.

To the OP: Have you tried the code in post 3 and have you tried your original code from posts 1 and 2 on another computer? Do you get the same results? I'm really thinking it's multiple versions of the JRE and one of them is corrupt, or it's a path problem. That's why I suggested typing in the full path for the javac and java programs. But I don't think this is a problem with the code itself.

Yeah, I think that is what vidaj was talking about. . if the OP wasn't running his code on the EDT, then I think vidaj was saying that is why it wasn't working.

There's no prohibition about running Swing code outside the EDT. It's just that the Swing code (with a few exceptions such as JLabel.setText) is not threadsafe, so if your code changes a Swing object from another thread you may get unpredictable results. In this particular case that's very unlikely, and certainly won't give a consistent failure.

ps: I agree with BJSJC re Swing code & tutorials. And while I think SerialUID is useless most of the time, I do not agree that you should just ignore them. The people who designed and built Java surely know something about the subject?

Frames are the basics of java gui...make frame then u can put any thing on it ... u can add ur custom panes just by overriding the paintComponent method of JPanel...n dont forget to add(frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE)) in ur code.

This article has been dead for over six months. Start a new discussion instead.