本文转自Java Swing开发团队Alexander Potochkin的Blog。Alexander 说，对于长期未曾更新博客，我感到十分的抱歉。这是由于最近Java Swing开发团队有个非常紧急的临时任务要完成，但是现在，我很开心的告诉大家，我们大部分的任务已经完成了，我们又可以把工作重心回归到初始设定的Swing library了.
这次是Swing应用框架真正的回归，这个项目也将是目前Swing团队工作的重中之重。我们还编组了一小队人马作为SAF的探路者，按部就班的开展工作。我的队友们总喜欢问我“当前的SAF究竟存在什么样的问题？”“究竟我理想中的SAF是什么样子？”每当这时代码就开始在我的脑海中翻滚。
这篇博文，将会为我的同僚们和Swing程序员们解答上述的问题。
已有代码的单例问题
使用静态方法Application.launch（）保存当前的应用程序实例到一个静态空间，同时用Application.getInstance（）返回结果。
其目的是防止不同的AppContexts向同一个JVM内核发出请求。想象一下，如果两个applet在同一个html上发出请求，他们将在同一个JVM内核中运行，分享不同类的静态数据，因此其中一个applet不能在使用Application.getInstance（）返回到自己的实例中了。
设计类试图
让我们先来看一看描述Java Swing开发类的javadoc文本：
*一个涵盖顶层应用GUI组件的视图，与JFrame和 Applet类似。它的主界面部分包含：菜单栏，工具栏，组件和一个状态栏，所有这些内容都是可选的（尽管没有主要组件的视图看起来会很奇怪）。*
类试图包含多种调用方法，例如：getMenuBar()/setMenuBar(), getToolBar()/setToolbar() and getRootPane()。
当每个视图都有自己的框架，而每个框架也拥有自己的菜单栏时，MDI应用程序可以正常工作。这就好像是大多数本地应用程序可以在Windows和Unix上运行一样。然而，一个出色的框架还要同时支持SDI应用程序，在Mac操作系统上，所有应用程序的视图都在共享同一个菜单栏，这种用视图定做主菜单栏的方法要比为每个视图配备相应的菜单栏更为方便。也正因此，在Mac应用软件中，发现一个只有一个菜单栏却没有主要组件的视图并不稀奇。
独立应用框架与JFrame绑定.
一个优秀的框架应具有友好的IDE交互，比方说，我希望用我最为喜爱的IDE设计软件去建立一个独立应用框架。在这种情况下，我不应该明确地使用类似于JFrame或JDialog的类，因为这将让使用IDE去控制和设计一个真正的JFrame变得非常困难的。
Applets是更为明显的例子，作为一个Applets和一个独立的应用程序，它在运行独立应用框架时应更加得心应手。它的常见模式将提供各类建立JFrame所必需的数据，却并不明确的创建它，而是容许不同的父窗体用不同的方法来展示这些视图。
不支持活动菜单
我并不是Mac用户，但是当我了解要想让Swing应用程序能在Mac系统上像本地程序一般运行是多么困难时，是这样的印象深刻。菜单栏是一个主要的问题，它与Mac不同，具体参见下文。我不得不说，SAF需要自动解决这类问题。
理想框架
一个小巧灵活，每个部分都有很强的功能性并且容易被重载。比如，当你不想执行LocalStorage时，它将很容易帮你停止目前的执行任务。它可以避免目前Java Swing开发中的问题，还知道如何让一个应用程序可以在特定操作系统上运行。
当下问题
我提到过，目前我们只针对一部分SAF的问题展开了讨论。你对我提出的问题有什么想法吗？或者你觉得SAF应该具有什么必须的工能呢？
【编辑推荐】
