下面是一些简单的 ― 但基本的 ― 更改，这样，您将可以充分利用改进了的 AWT 焦点子系统。
使用 Component.requestFocusInWindow()
因为某些平台允许跨窗口的焦点更改而其它平台不允许，所以 Component.requestFocus() 在各个平台之间是不一致的。 Component.requestFocusInWindow 通过提出任何平台都不允许跨窗口的焦点遍历解决了这个问题。此外， requestFocusInWindow() 返回一个布尔值：false，意味着该焦点请求将失败;true，则意味着该焦点请求可能通过。请注意，您不应该假定组件在调用 requestFocus() 或 requestFocusInWindow() 后收到了焦点。而应该给组件安装一个焦点侦听器，并查找 FOCUS_GAINED 事件。
使用 java.awt.KeyboardFocusManager
如果您曾经把 javax.swing.FocusManager 用于获取 Swing 组件的焦点更改的全局视图，那么，您可能已经注意到它的局限性了。 FocusManager 无法了解由鼠标激活的焦点更改，而且更重要的是，它只能处理 Swing 组件。因为 KeyboardFocusManager 是个 AWT 类，它可以了解所有组件发生的事，而不仅仅是那些属于 Swing 的组件的事。此外， KeyboardFocusManager 具有一个改进了的 API 的特征。
使用 Swing 组件
因为 AWT 遵循本机平台的需求，所以应用程序的行为在不同平台上可以不一样。
例如，让我们设想您定义了一个 myComponent 类，它继承 Component 并覆盖 isFocusTraversable() 方法以返回 false。换句话说，该类的任何实例都是不可遍历的。现在，让我们来设想某个应用程序把一个 myComponent 的实例添加到某个框架，还添加了未覆盖 isFocusTraversable() 方法的其它组件(按这个顺序)。当应用程序启动时哪个组件得到了初始的焦点呢?文档中没有明确定义。
虽然，下一个焦点可遍历的可见组件获取初始的焦点也是合理的，但这的确依赖于本机焦点管理器。您会在某些平台上看到上面描述过的行为，但是，什么组件都没有得到焦点的情况也会发生。这导致了 isFocusTraversable() 的“可以用 Tab 或 Shift-Tab 遍历”被重定义为“可以被定焦”。这只是 AWT 很大程度上依赖本机焦点管理器的许多示例之一。正如当 AWT 的行为在新的发行版中逐渐变得一致时，Swing 也将会更好的确保跨平台的一致性。
