我建议您看一下JSR 296-尚未完成，但我认为它达到了在每个Java
GUI应用程序中提供您确实需要的某些核心功能的最佳位置，而不会强迫您继续生活一个过于复杂的框架。
我已经成功地使用JSR
296创建了中型应用程序。对于此应用程序中的窗口布局，我们使用MyDoggy（强烈建议）。对于布局管理，我们使用MiGLayout（强烈建议不要使用）。对于数据绑定，我们使用JSR
295的修改形式（在GUI绑定中，我们在JSR
295的顶部实现了与PresentationModel类似的功能）。我正在将Guice用作DI机制，但尚未完成这项工作（到目前为止，我认为它会在JSR
296上进行一些调整，从而“很好地”发挥作用）。让我们看看…持久性是这里缺少的主要环节-
我目前正在评估Simple的XML持久性，但是在使其与Guice等DI容器一起使用时遇到了问题。我有Betwixt
工作正常，但是对Betwixt的依赖性很大，因此我们正在寻找更简化的方法。
关于Java的其他RCP选项的观点：
NetBeans：我对NetBeans所使用的方法有一些基本的哲学异议（我喜欢太多的设计反模式）。最后，该框架迫使您做出糟糕的设计决策-
如果您不使用NetBeans作为您的IDE，几乎是不可能使用的（我尝试过，但是我无法从Eclipse切换到NB）。可能只有我一个人，但是似乎可以为RCP框架编写代码，而无需使用大型复杂的向导和大量自动生成的代码和XML文件。我花了很多时间对由Visual
Studio生成的旧的Visual C ++代码进行故障排除，以至于对任何无法手动编写的框架都持怀疑态度。
Spring RCP：Spring的人员具有良好的整体设计，但是文档确实非常虚弱。加快速度非常困难（但是一旦完成，您就可以很快完成工作）。
Eclipse RCP：仅仅由于部署开销而没有使用Eclipse（取决于您的目标受众-对我们来说，额外部署50
MB的运行时就是行不通的）。毫无疑问，如果您的应用程序需要重要的插件功能（当然，您也可以在JSR
296上运行Equinox，或者使用类似于OSGi推广的Whiteboard模式的设计模式），Equinox就是一件美丽的事情。
