Rob Spoor wrote:Why I still do it then? Habit I guess. Laziness as well probably.
I think it's a conceptual thing. If you think of the frame being the application (which for many single-window applications it's perfectly understandable), then extending JFrame makes sense. The application IS-A frame.
I'm not saying I think it's brilliant design, although I also do it myself occasionally. But I don't think it necessarily leads to bad code. One place it really falls down is if you might feasibly want to convert the application to a different framework.
An application is not a JFrame and it never will be. In my mind, the JFrame models the outermost rim of the application (like the frame of a picture), and only includes the system menu, the state buttons; it has a dimension and it holds the various panels the application may make use of. It also does all of this just perfectly, without any ambiguity, so there's never any reason to extend it, unless you want to add new system buttons, or functionality, like being able to pin it to the foreground or something like that (which at this point I'm not entirely convinced you can't do in another way).
The same application may work just fine in a console, in a dialogue, in an applet, etc. By letting it extend a JFrame, you're also making that part of your application's API; effectively binding your application to a JFrame forever. Of course it doesn't matter much if you make the main class package private, but I don't see why you wouldn't take 2 extra minutes to do it properly.
People usually seem to treat their main class differently than they would other, better designed classes that are deeper inside the application. They think: "this class is only important to this particular application, or this particular version of it, so I can just quickly throw something together".