Sapphire是一个新提出的Eclipse项目，旨在简化UI开发。 JAXenter与最初的提交者Konstantin Komissarchik进行了交流，以了解Sapphire如何与e4，EMF相适应，以及Oracle为什么要帮助将Sapphire开发为Eclipse项目……。

JAXenter：您认为编写Java桌面UI的当前陷阱是什么？

Konstantin Komissarchik：无论使用哪种窗口小部件工具包，开发人员使用的API都旨在优化灵活性并尽可能减少假设。 如果您要开发真正独特的东西，那就太好了，但是每天编写的大部分UI都不能从这种灵活性中受益。 实际上，它受到了伤害。 实现简单的屏幕不仅需要大量工作，而且很难实现一致性。 开发人员实现了不同的UI模式来解决相似的问题。 在诸如布局，按钮宽度和边距之类的普通项目上花费了大量的时间来实现一致性。

令人惊讶的是，仅用一个浏览按钮显示一个文本字段就必须编写多少UI代码，确保发生数据绑定和验证问题浮出水面。 该代码成为产品的维护责任。 甚至最好的开发人员也陷入使UI组件直接与其他UI组件进行对话的陷阱。 由此产生的事件处理程序网络将来几乎不可能维护和发展。

最重要的是，所编写的代码与特定的窗口小部件工具箱相关联。 如果要将应用程序从Swing迁移到Eclipse RCP，则必须从头开始重新编写所有UI。 如果您有一个满意的桌面应用程序，但是要添加基于浏览器的客户端，则必须再次从头开始。

JAXenter：像Sapphire一样，用UI中的属性编辑器替换小部件有什么好处？

Konstantin Komissarchik： Sapphire方法的好处是，开发人员告诉系统他想完成什么而不是如何完成。 使用Sapphire，开发人员说“我要编辑人员对象的LastName属性。” 使用SWT之类的小部件工具箱，开发人员说“创建标签，创建文本框，像这样布置它们，配置其设置，设置数据绑定等。”

使用Sapphire，类似的数据模式将以类似的方式出现在UI中。 不仅如此，UI定义从本质上讲更加可移植。 由于Sapphire并未规定编辑给定属性的确切方式，因此渲染器的实现者可以选择一种最适合他们所针对的平台的方法。 相同的UI定义可以生成用于丰富桌面体验的SWT应用程序，以及可以在恶劣的网络条件下在旧浏览器中运行的Web应用程序。

JAXenter： Sapphire和e4的UI规范声明方法有何不同？

Konstantin Komissarchik： e4 UI定义由单个小部件组成UI，而Sapphire UI定义由属性编辑器组成UI。 两者都有自己的位置。 e4项目将产生下一代Eclipse RCP，并具有处理任意复杂的UI需求的能力。 蓝宝石将位于此之上，并将提供一种高级语言，适用于要求更为平凡的大多数情况。

JAXenter：对于Sapphire，您为什么选择不使用EMF作为建模框架？

Konstantin Komissarchik：我们花了很多时间在内部进行辩论。 实际上，第一次尝试是基于EMF。 最终，它归结为易于使用并且学习曲线浅。 我们使用Sapphire的目标是改善开发人员编写UI的方式。 尽管我们的方法以数据模型为中心，但从根本上讲，我们并不是在促进建模。 归结为尽最大努力利用典型Java开发人员已经具备的知识。 我们不想学习复杂的建模框架成为采用的障碍。 例如，Sapphire的建模框架使用Java批注，并且对进行JAXB或JPA开发的任何人都会很熟悉。

同时，我们不希望将已经在EMF上进行投资的开发人员从Sapphire中受益。 我们对探索蓝宝石可以利用现有EMF模型的方式感兴趣。

JAXenter： Sapphire的最初代码贡献来自Oracle的Eclipse Enterprise Pack。 Oracle将Sapphire开发为Eclipse项目的动机是什么？

Konstantin Komissarchik：多种动机导致了这一举动。 首先，OEPE利用来自Eclipse项目的工具来为Oracle客户创建完整的解决方案。 如果这些项目可以使用Sapphire，那么随着项目能够更快地生成高质量的UI，我们可以看到针对标准技术的更好工具。 当然，这直接使Oracle受益。

我们还意识到，我们自己无法充分发挥蓝宝石的潜力。 例如，我们目前只有一个SWT渲染器。 我们很乐意与Eclipse社区的其他成员一起建立高质量渲染器库，因为这将为每个人增加Sapphire的价值。