The main idea I didn't get from the Sun tutorial.

Newbie & Debugging Questions
#21

To me, extending JFrame for your main application window does make logical sense. If during development you think, “Maybe my main window’s layout should be a little different to make things more intuitive…”, which class seems most logical to look in for that window’s layout? I think it would be a class defining the window itself. If there were no such class, you’d think, “Okay, where is the code that creates my main window?” There’s no immediately obvious answer (okay, maybe if you wrote the entire app yourself so you’re familiar with it…). If you inherit someone else’s code, or download someone else’s open source project to work on, you’d have to resort to skimming through class file names to find one that seemed like it was where the job was done. Maybe not the worst case in the world, but it sure seems less intuitive than say “MainWindow.java” to me.

To me, extending JFrame is both of these things. But I’m surely biased on this point since it’s the way I always do things, so I can’t argue against it.

Perhaps I’ll try not extending JFrame on my next project. Maybe I’ll change my tune. :slight_smile:

#22

If you decide to extend a JFrame it might make more sense to extend JPanel instead. If you extend JPanel you can put it into a JFrame or JApplet.

#23

Yes, I mentioned doing this in my first post in this thread. I don’t think this is a bad idea, but you’d still lose out on sharing some things such as a JMenuBar and glass pane (as Mr. Light mentioned), so you’d still have code duplication between the JApplet and the JFrame versions. Perhaps as Mr_Light mumbled, extending a JRootPane is a better choice if you choose to go this route.

#24

To you who don’t think one should extend JFrame or similar; what should you do instead?

I’m a newbie at Java, and I’ve set out to do the following:
Use swing and make an application that can read my mysql database and show it’s contents, and possibly alter it.

Every tutorial that Sun provides extends either Frame, JFrame, JPanel or something similar.

What would you suggest me to do?

Also, can anyone recommend me a forum that’s not game-specific for java. A place where I could get help with the application mentioned above. Not that I couldn’t get it here, but there are probably more appropriate places.

#25

Just do as the tutorials do.

After you worked with it for a few months, gained some experience, you might or might not want to change your code.

#26

Okey well right now I’m looking at 3 different things to extend. Not sure which one to use.
JFrame, JPanel or simply Frame?
Or perhaps the JRootPane mentioned previously?

The main reason I’m wondering is of what you said:

“Extending JFrame/JPanel when just using it, does neither, you write more code and it makes no sense.”

That had me believe there’s a better way that has you writing less code.

#27

Well, my way is to create your normal classes, that simply use Swing classes.

Instead of this:


public class PersonForm extends JPanel
{
   private final JButton closeButton;

   public PersonForm()
   {
      closeButton = new JButton("close");

      this.setLayout(...);
      this.add(closeButton, someConstraint);
   }
}

I code it like:


public class PersonForm
{
   private final JPanel panel;
   private final JButton closeButton;

   public PersonForm()
   {
      closeButton = new JButton("close");

      panel = new JPanel();
      panel.setLayout(...);
      panel.add(closeButton, someConstraint);
   }
}

Now this might not be the best of examples, and certainly doesn’t show any advantages, except the principle that as long as you’re not extending functionality (or changing behavior) of a JPanel, you shouldn’t extend it…

#28

Alright well I’m with you so far.

But will this approach show any disadvantages further into the development process?

#29

I don’t see any real disadvantages. You’d have to provide a PersonForm#getPanel() method that returned the JPanel in order to add it to a parent container, but that’s no biggie.

You could also argue that this is a step in the right direction if you wanted to have multiple UI’s, or the possibility of multiple UI’s. For example, your app might be Swing-based today, but tomorrow you may decide to use SWT instead. You could make a “PersonForm” interface/abstract class/whatever, and have a concrete Swing implementation, and on the switch to SWT just create an SWT implementation. If your entire GUI was created like this, then the application logic would be completely shielded from your GUI toolkit switch.

#30

As mentioned, the provided example is hardly showing any advantages.

I have written very large swing administration-applications with this approach though, so it certainly won’t get you into more trouble than you’d otherwise find yourself in. :slight_smile:

I just like to keep my functionality independant of Panels.
What if you have this great form, but in another part of your program you want to put that JTextArea / JButton on a neighbouring JPanel. When you provide your form as a JPanel, you’d be pretty much stuck, as all your components must be in that single JPanel.

IMHO in MVC, a View can be very well detached from a JPanel (or JPanel-hierarchy)

#31

To me it seems that Riven is saying that the “Inheritance is Evil” rule should apply here. That rule says that whenever you have a choice, you should prefer composition to inheritance (which means adding functionality by calling out to members rather than extending classes). That’s especially true when you’re not actually extending the functionality of a class, you’re just using it.

It’s a bit tough to justify the rule in a simple example, but suffice it to say that the rule tends to show up pretty high on the OO-advice list of most experienced designers (in any OO language, not just Java - the C++ guys have been screaming about this for decades). The gist of it is that IS-A is a much tighter coupling between classes than HAS-A, so changes in one class are far more likely to have side effects outside of that file, which makes maintenance that much more of a bitch. Even Gosling is often quoted (usually by functional programmers that think objects are ruining Real Programming) as saying that the “extends” keyword is one of the worst things about Java - programming to an interface and using composition leads to more maintainable systems in most situations.

In this case it’s not a huge deal, since JPanel is for all intents and purposes frozen in time because Sun doesn’t want to piss off its entire user base (so you’re not likely to have surprise name clashes or anything like that), but it’s not gaining you anything to extend it, and it’s a bad habit to get into. The fact that all the Java tutorials use JPanels by extending them is particularly annoying, since it implies that there’s some reason you need to extend them in order to use them, which is just not true, and it’s very confusing to newcomers.

#32

Take a look at the average “hello world” introduction to Swing (or worse: introduction to Java!)

How many years does it take one to fully grasp this code:


public class MyFrame extends JFrame implements ActionListener
{
   public static void main(String[] args)
   {
      new MyFrame("Hello World");
   }

   public MyFrame()
   {
      JButton b = new JButton("click me");
      b.addActionListener(this); // BLACK MAGIC for n00bs

      // what is 'this' ?

      this.setLayout(new BorderLayout());
      this.add(b, BorderLayout.NORTH);
      this.pack();
      this.setVisible(true);
      this.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); // SAY WHAT?
   }

   public void actionPerformed(ActionEvent event)
   {
      System.out.println("you clicked me");
   }
}

And why this code crashes or just hangs every once in a while, as we are manipulating Swing from the main thread!

This is very much like how my classmates learned to write their first few lines of Java, when wondering what the difference between an Object, a primitive and a Class was - not to mention Interfaces like ActionListener would be coded ‘because the sample code had them’. Anyway… just to show how completely f*cked up most of us (?) got introduced to the wonderful world of programming.

Our teacher was to bad, that he had code like MyFrame, MyButton, MyPanel, MyList - just for implementing the event listeners. And when there was nothing to listen for, I stumbled across:

public class MyCheckbox extends Checkbox {
public MyCheckbox() {
super();
}
}

and

public class MyMap extends HashMap {
public MyMap() {
super();
}

public void myPut(Object key, Object value) {
this.put(key, val);
}
}

Okay… that’s enough offtopic stuff for today.