Inheritance because you can is no reason to use inheritance. 99.999999% of the time, you gain nothing by extending JFrame. The other .000001% is for those that need something a bit more *special* than whatever JFrame currently provides. Quite rare.
but wont you save code? i atleast think its easier to just extend JFrame instead of JFrame pointer = new JFrame(); because you dont all the the time you use the methods write pointer.method(), you can just write method()?
You'll be surprised at how very little you'll need to do on the JFrame instance itself. It's really just creating it, setting a title (those are 1 line combined), setting an initial size, and then managing the listeners (close, resize, etc), which are handled the exact same way whether you use inheritance or not.
It helps to point out that long, long ago, before the Earth cooled, and dinosaurs roamed the land, lo! There was no Swing! There was only AWT. And in fact, there was The Old AWT, before the Java 1.1 Event Model changed everything. Gather around, children, and heed these words.
In this mystical long-ago land, extending a component was the only way to respond to events! Verily, it was so. Thou wert required to extend Frame (or Panel, or Canvas) or the buttons could not beseech thee to action. And to make marks upon the fertile field of the grey Panel, lo! Again, inheritance was the one true way.
Perchance and anon, thou might comest across a scroll from these ancient days, or one from an elder author who remembers that time. And it will be not good, for it shall beseech thee to follow this long-eroded path, which leads only to madness and Bad Code. Come towards the light and be saved! Don't extend components unless you're actually changing the behavior of a component!
Interesting discussion , and more interesting information by EFH here! Thanks for the insight on a little bit of history.
I usually extend JFrame when I want to maintain it as a "common reference point" for all child components. Lots of common code is also abstracted to it. This way, I end up with an extended JFrame instance, typically with a static getter method, and lots of pass through methods. Agreed this is not why one should be using inheritance, but it adds to my convenience. Of course this is a personal opinion and YMMV your mileage may vary.
If you use the NetBeans IDE and the GUI builder that NetBeans has, and you use the wizard to create a new JFrame form, it will generate a class for you that extends JFrame (and probably the GUI builder even expects it to be that way).
Since your class that extends JFrame really represents the window you're creating, I don't see any problem in this case with using inheritance. If you'd use inheritance only because you need functionality from the superclass (and there is no clear "is a" relationship between the superclass and the subclass) then I'd object ( ) to it.
Now for me it's clear, when I need only the functionality of the Jframe I will use a method to use it. But now I have another confusion, how do I at the actionlistner?
Do I at it to the class where the object new JFrame() is created or can I add it directly to the object of new JFrame()?
Another Question I have: for what reason do I extend from JPanel?
Although I too often extend JFrame for my user interfaces, it's indeed not good design. A sub class should add new functionality, and the contents of a user interface is not new functionality. That's the same as extending ArrayList to add some elements in the constructor. The controls can be removed after the JFrame has been created, breaking the entire user interface.
Why I still do it then? Habit I guess. Laziness as well probably. When I create a proper JComponent subclass I make sure I override the add / remove / layout methods to make sure my user interface stays intact. Something Sun hasn't done with most Swing components by the way - try adding a JButton to a JTable using the add method.