在许多情况下，为了启用和禁用菜单项而限制菜单修改是很实际的。此方法容易受到用于禁用项的常规警告的影响：避免由于偶然地禁用重要项而使程序处于不可用状态。
添加或删除菜单项或子菜单也是可能的。修改 JMenuBar 没有这么容易;没有从工具栏上删除和替换单个菜单的接口。如果您想修改工具栏(而不是向最右端添加菜单)，需要制作一个新的工具栏并用它替换旧的工具栏。
修改单个菜单会立即生效;您不必在将菜单连接到工具栏或另一个菜单之前构建一个菜单。当需要修改菜单选项的选择时，最容易的方法是修改选定的菜单。您可能仍然想添加或删除完整的菜单，并且这么做并不是特别难。清单 6 显示一个将菜单插入到菜单条中给定索引前的方法的简单示例。此示例假定要替换的 JMenuBar 连接到 JFrame 对象，但是任何能使您获得和设置菜单条的东西的工作方式都是一样的：
清单 6. 把一个菜单插入到菜单条中
2 JMenuBar newBar = new JMenuBar();
3 JMenuBar oldBar = frame.getJMenuBar();
4 MenuElement[] oldMenus = oldBar.getSubElements();
5 int count = oldBar.getMenuCount();
6 int i;
7
8 for (i = 0; i < count; ++i) {
9 if (i == index)
10 newBar.add(menu);
11 newBar.add((JMenu) oldMenus[i]);
12 }
13 frame.setJMenuBar(newBar);
14 }
15
上面的代码我不是开始时就试图编成这样;这是最终的版本，已经很好地修复过了所以它能够运行并反映一些有趣的怪事。初看起来，实现此功能的明显方法似乎应该是使用 getComponentAtIndex()，但是这种方法已经受到了反对。幸运的是，getSubElements() 已经足够好。为 newBar.add() 而进行到 JMenu 的强制类型转换可能是安全的，但是我不喜欢这样。getSubElements() 接口不仅对菜单条而且对菜单进行操作，菜单可能具有几种类型的子元素，JMenu 是可以添加到 JMenuBar 的惟一元素。所以必须把元素强制转换为 JMenu 以把它传递到 JMenuBar.add() 方法。不幸的是，如果将来的 API 修订版允许将除 JMenu 类型之外的元素添加到 JMenuBar，就不再需要把返回的元素强制转换 JMenu了。
清单 6 中的代码反映了另外一个相当微妙的界面怪事;菜单数必须提前缓存起来。当把菜单添加到新的菜单条时，它们从旧的菜单条中被删除。虽然看起来相似，但是清单 7 中的代码不能工作，因为循环提前结束了:
清单 7. 循环结束太早
2 for (i = 0; i < oldBar.getMenuCount(); ++i) {
3 if (i == index)
4 newBar.add(menu);
5 newBar.add((JMenu) oldMenus[i]);
6 }
7
清单 7 中的循环只复制一半数量的菜单。例如，如果开始菜单条上有 4 个 菜单，它复制前面的两个菜单。复制完第一个菜单以后， i 的值为 1 并且 getMenuCount() 返回 3;在复制完第二个菜单以后，i 的值为 2 并且 getMenuCount() 返回 2，因此循环结束。我没有找到任何介绍通过向菜单条添加菜单从而从另一个菜单条删除菜单这样的特性的文档，因此可能不是有意这样。但是，它很容易达到这个目的。
从菜单条删除菜单稍微容易一些;只是把所有其他的菜单从旧的菜单条复制到新的菜单条，就完成了删除菜单。很容易!
如果界面使用了很多动态菜单更新，创建一组菜单条并在它们之间切换而不是一直动态地更新它们也许会更好一些。但是，如果如此快地改变菜单，可能会使用户完全发疯。
勘误：在本文的草稿阶段，我忽略了 JMenuBar 类的继承方法的列表。其实，它有 remove 和 add 方法可以用来在指定的索引处进行删除和插入。另外一个教训是：查看继承的方法而不仅仅是特定于类的方法。
调整窗口大小
所幸的是对于大多数情况，窗口大小调整是自动进行的。但是需要考虑调整大小产生的一些影响。在非常小的窗口中，按钮条、菜单条和类似功能可能变成有问题的。管理程序自身的图形面板需要响应调整大小事件。让 Swing 处理对 UI 元素的包装，但是要密切注视组件的大小;不要获取一次组件的尺寸然后就一直使用这些值。
更微妙的地方是，一些设计决策(例如滑块上刻度的密度)可能被适度地更新以响应窗口大小调整事件。100 像素宽度的滑块不能具有像 400 像素宽度的滑块那样多的可读标签。您可能想通过添加全新的有用功能来让 UI 更进一步用在大型显示器上。
但是，在多数情况下，可以忽略窗口大小调整。您不应该做的是不必要地阻止或重写它。布局代码中的窗口一侧的便捷工具不是必需的。最小的窗口大小可能是无可厚非的，但是要让人们能把窗口调整到他们所需要的大小。
一般原则
Swing 工具包在 UI 设计方面提供了很大的灵活性。如果小心地使用，动态更新界面的选项能够极大地简化该界面;例如，只有应用菜单的选项时，用户才能容易地显示菜单。
不幸的是，一些 API 的特性可能使此方法产生一些离奇的行为，并且副作用和相互影响并不总是像您期望的那样记录下来。如果您有使用动态界面的想法，就要准备在调试上花费一些额外的时间。您可能从 Swing 库的困境中走出来并发现自己需要处理出人意料的行为和/或 bug。
不要让缺乏明显的实现让您气馁。像本文的 JMenuBar 示例所显示的，即使当 API 不支持某个任务时，您也能自己实现它，虽然有一点间接。
尽量不要走极端。当动态 UI 让用户清楚它们的固有限制时，它们才能最好地发挥作用。理想的情况是，用户甚至可能不会注意到界面变化。如果他们能够使用程序的 Object 菜单的惟一时刻是当他们使某个对象被选择时，那么其余的时间他们将不会介意不存在该菜单。
另一方面，如果存在这种可能性：用户不能猜测出一个选项不可用的原因，这时让用户尝试操作并获得包含信息的消息也许会更好。这对于一些操作尤其重要。如果保存选项被禁用，而我想保存数据，那么这不会发生作用。程序可能认为已经保存了数据，但是为什么不让我无论如何都保存它呢?如果存在不能保存文件的特殊原因，我可能想知道是什么原因。
尽管研究了很多年，界面设计在很多方面仍旧是一个较新的领域，只进行了很少的试验。动态改变 UI 是一个很好的特性，能够使 UI 更清晰、更简单和反应更迅速。添加动态特性需要从几分钟的工作到大量时间的花费不等。
