Using Multiple JFrames in java ? is it a good practice?6 min read

The multiple JFrame approach in java has been something I’ve implemented since I began programming Swing apps. For the most part, I did it in the beginning because I didn’t know any better. However, as I matured in my experience and knowledge as a developer and as began to read and absorb the opinions of so many more experienced Java devs online, I made an attempt to shift away from the multiple JFrame approach. As I began implementing model dialogs to control “child” windows and JInternalFrames for separate components, I was quite surprised, as I was doing what I thought was best-practice! But, as they say, It is not a good practice.

So, I’m going to explain the benefits of the multiple JFrame approach, as well as myth-bust some of the cons that others have presented.

  1. Ultimate flexibility in layout – By allowing separate JFrames, you give your end-user the ability to spread out and control what’s on his/her screen. The concept feels “open” and non-constricting. You lose this when you go towards one big JFrame and a bunch of JInternalFrames.
  2. Works well for very modularized applications – In my case, most of my applications have 3 – 5 big “modules” that really have nothing to do with each other whatsoever. For instance, one module might be a sales dashboard and one might be an accounting dashboard. They don’t talk to each other or anything. However, the executive might want to open both and them being separate frames on the taskbar makes his life easier.
  3. Myth: Hard to code – This is not true in my experience. I don’t see why it would be any easier to create a JInternalFrame than a JFrame. In fact, in my experience, JInternalFramesoffer much less flexibility. I have developed a systematic way of handling the opening & closing of JFrames in my applets that really works well. I control the frame almost completely from within the frame’s code itself; the creation of the new frame, SwingWorkers that control the retrieval of data on background threads and the GUI code on EDT, restoring/bringing to front the frame if the user tries to open it twice, etc. All you need to open my JFrames is call a public static method open() and the open method, combined with a windowClosing() event handles the rest (is the frame already open? is it not open, but loading? etc.) I made this approach a template so it’s not difficult to implement for each frame.
  4. Myth/Unproven: Resource Heavy – I’d like to see some facts behind this speculative statement. Although, perhaps, you could say a JFrame needs more space than a JInternalFrame, even if you open up 100 JFrames, how many more resources would you really be consuming? If your concern is memory leaks because of resources: calling dispose() frees all resources used by the frame for garbage collection (and, again I say, a JInternalFrame should invoke exactly the same concern).

I feel like I could write more. Anyways,

A great example of multiple frames/single document per frame (SDI) vs single frame/multiple documents per frame (MDI) is Microsoft Excel. Some of MDI benefits:

  • it is possible to have a few windows in non rectangular shape – so they don’t hide desktop or other window from another process (e.g. web browser)
  • it is possible to open a window from another process over one Excel window while writing in second Excel window – with MDI, trying to write in one of internal windows will give focus to the entire Excel window, hence hiding window from another process
  • it is possible to have different documents on different screens, which is especially useful when screens do not have the same resolution.

Here is the Code to implement the Multiple JFrames

And the for the new Window

Take your time and comment on our article.

Leave a Comment