将jInternalFrame放入主框架中，并使其不可见。然后您可以将它用于进一步的事件。

jInternalFrame.setSize(300,150);
jInternalFrame.setVisible(true);

将jInternalFrame放入主框架中，并使其不可见。然后您可以将它用于进一步的事件。

jInternalFrame.setSize(300,150);
jInternalFrame.setVisible(true);

我只是想知道使用多个jframe是否是好的实践?

糟糕的做法。

User unfriendly: The user sees multiple icons in their task bar when expecting to see only one. Plus the side effects of the coding problems.. A nightmare to code and maintain: A modal dialog offers the easy opportunity to focus attention on the content of that dialog - choose/fix/cancel this, then proceed. Multiple frames do not. A dialog (or floating tool-bar) with a parent will come to front when the parent is clicked on - you'd have to implement that in frames if that was the desired behavior.

在一个GUI中显示多个元素的方法有很多，例如:

CardLayout (short demo.). Good for: Showing wizard like dialogs. Displaying list, tree etc. selections for items that have an associated component. Flipping between no component and visible component. JInternalFrame/JDesktopPane typically used for an MDI. JTabbedPane for groups of components. JSplitPane A way to display two components of which the importance between one or the other (the size) varies according to what the user is doing. JLayeredPane far many well ..layered components. JToolBar typically contains groups of actions or controls. Can be dragged around the GUI, or off it entirely according to user need. As mentioned above, will minimize/restore according to the parent doing so. As items in a JList (simple example below). As nodes in a JTree. Nested layouts.

但是如果这些策略不适用于特定的用例，请尝试以下方法。建立一个主JFrame，然后将JDialog或JOptionPane实例用于其余的自由浮动元素，并使用该框架作为对话框的父元素。

许多图片

在这种情况下，多个元素都是图像，最好使用以下任何一种:

一个单独的JLabel(位于滚动窗格的中心)，用于显示用户当时感兴趣的任何图像。在ImageViewer中可以看到。 单行JList。从这个答案中可以看出。“单行”部分只有在它们都是相同尺寸的情况下才有效。或者，如果你准备在飞行中缩放图像，并且它们都是相同的纵横比(例如4:3或16:9)。

这是一段时间以来，我最后一次接触摇摆，但一般是一个坏的做法，这样做。我想到的一些主要缺点是:

It's more expensive: you will have to allocate way more resources to draw a JFrame that other kind of window container, such as Dialog or JInternalFrame. Not user friendly: It is not easy to navigate into a bunch of JFrame stuck together, it will look like your application is a set of applications inconsistent and poorly design. It's easy to use JInternalFrame This is kind of retorical, now it's way easier and other people smarter ( or with more spare time) than us have already think through the Desktop and JInternalFrame pattern, so I would recommend to use it.

The multiple JFrame approach 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 (both in current projects and future projects) only to be met with... get this... resistance from my clients! As I began implementing modal dialogs to control "child" windows and JInternalFrames for separate components, my clients began to complain! I was quite surprised, as I was doing what I thought was best-practice! But, as they say, "A happy wife is a happy life." Same goes for your clients. Of course, I am a contractor so my end-users have direct access to me, the developer, which is obviously not a common scenario.

因此，我将解释多JFrame方法的优点，并戳破其他人提出的一些缺点。

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. 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. Makes it easy for end-users to reference outside material - Once, I had this situation: My app had a "data viewer," from which you could click "Add New" and it would open a data entry screen. Initially, both were JFrames. However, I wanted the data entry screen to be a JDialog whose parent was the data viewer. I made the change, and immediately I received a call from an end-user who relied heavily on the fact that he could minimize or close the viewer and keep the editor open while he referenced another part of the program (or a website, I don't remember). He's not on a multi-monitor, so he needed the entry dialog to be first and something else to be second, with the data viewer completely hidden. This was impossible with a JDialog and certainly would've been impossible with a JInternalFrame as well. I begrudgingly changed it back to being separate JFrames for his sanity, but it taught me an important lesson. 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, JInternalFrames offer much less flexibility. I have developed a systematic way of handling the opening & closing of JFrames in my apps 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. 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).

我写了很多，我觉得我还能写更多。不管怎样，我希望我不会因为这是一个不受欢迎的观点而被否决。这个问题显然很有价值，我希望我提供了一个有价值的答案，即使它不是普遍的观点。

多帧/每帧一个文档(SDI) vs单帧/每帧多个文档(MDI)的一个很好的例子是Microsoft Excel。MDI的一些好处:

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

SDI (single - document Interface，即每个窗口只能有一个文档):

MDI(多文档接口，即每个窗口可以有多个文档):

绝对是坏习惯。一个原因是它不是很“用户友好”，因为每个JFrame都显示一个新的任务栏图标。控制多个jframe会让你抓狂。

就我个人而言，我会为您的应用程序使用ONE JFrame。显示多个东西的方法取决于你，有很多。画布，JInternalFrame, CardLayout，甚至JPanels可能。

多个JFrame对象=痛苦、麻烦和问题。