在许多情况下，为了启用和禁用菜单项而限制菜单修改是很实际的。此方法容易受到用于禁用项的常规警告的影响：避免由于偶然地禁用重要项而使程序处于不可用状态。

添加或删除菜单项或子菜单也是可能的。不过修改菜单栏(JMenuBar)没有这么容易，Swing没有从菜单栏(JMenuBar)上删除和替换单个菜单的接口。如果您想修改菜单栏（而不是向最右端添加菜单），需要制作一个新的菜单栏并用它替换旧的菜单栏。

修改单个菜单会立即生效，您不必在将菜单连接到工具栏或另一个菜单之前构建一个菜单。当需要修改菜单选项的选择时，最容易的方法是修改选定的菜单。 您可能仍然想添加或删除完整的菜单，并且这么做并不是特别难。下列代码 显示一个将菜单插入到菜单条中给定索引前的方法的简单示例。 此示例假定要替换的 JMenuBar 连接到 JFrame 对象，但是任何能使您获得和设置菜单条的东西的工作方式都是一样的：
 
java代码： 把一个菜单插入到菜单条中

public void insertMenu(JFrame frame, JMenu menu, int index) {
       JMenuBar newBar = new JMenuBar();
       JMenuBar oldBar = frame.getJMenuBar();
       MenuElement[] oldMenus = oldBar.getSubElements();
       int count = oldBar.getMenuCount();
       int i;
 
       for (i = 0; i < count; ++i) {
              if (i == index)
                     newBar.add(menu);
              newBar.add((JMenu) oldMenus[i]);
       }
       frame.setJMenuBar(newBar);
}

上面的代码我不是开始时就试图编成这样，这是最终的版本，已经很好地修复过了所以它能够运行并反映一些有趣的怪事。初看起来，实现此功能的明显方法似乎应该是使用 getComponentAtIndex()，但是这种方法已经受到了反对。幸运的是，getSubElements() 已经足够好。为 newBar.add() 而进行到 JMenu 的强制类型转换可能是安全的，但是我不喜欢这样。getSubElements() 接口不仅对菜单条而且对菜单进行操作，菜单可能具有几种类型的子元素，JMenu 是可以添加到 JMenuBar 的惟一元素。所以必须把元素强制转换为 JMenu 以把它传递到 JMenuBar.add() 方法。不幸的是，如果将来的 API 修订版允许将除 JMenu 类型之外的元素添加到 JMenuBar，就不再需要把返回的元素强制转换 JMenu了。

上面的代码反映了另外一个相当微妙的界面怪事，菜单数必须提前缓存起来。当把菜单添加到新的菜单条时，它们从旧的菜单条中被删除。虽然看起来相似，但是下面的代码不能工作，因为循环提前结束了:
 
java代码： 循环结束太早

// DOES NOT WORK
for (i = 0; i < oldBar.getMenuCount(); ++i) {
       if (i == index)
              newBar.add(menu);
       newBar.add((JMenu) oldMenus[i]);
}

界面保持一致性对用户有益，特定的菜单应该总是位于相同的位置。为了用户的方便，应该把可能改变的菜单放置在菜单列表的右端，把不会改变的菜单放在 左边的固定位置。同样地，当可能的时候，把菜单项放置在菜单中的相同位置。变灰的菜单项比时而添加时而删除的菜单项对用户具有更少的干扰性，因为菜单中的 其他菜单项不会来回变动位置。

上面的代码中的循环只复制一半数量的菜单。例如，如果开始菜单条上有 4 个 菜单，它复制前面的两个菜单。复制完第一个菜单以后， i 的值为 1 并且 getMenuCount() 返回 3；在复制完第二个菜单以后，i 的值为 2 并且 getMenuCount() 返回 2，因此循环结束。我没有找到任何介绍通过向菜单条添加菜单从而从另一个菜单条删除菜单这样的特性的文档，因此可能不是有意这样。但是，它很容易达到这个目的。

从菜单条删除菜单稍微容易一些，只是把所有其他的菜单从旧的菜单条复制到新的菜单条，就完成了删除菜单。很容易！

如果界面使用了很多动态菜单更新，创建一组菜单条并在它们之间切换而不是一直动态地更新它们也许会更好一些。但是，如果如此快地改变菜单，可能会使用户完全发疯。