Sapphire: the first attempt was EMF-based.
JAXenter speaks with Konstantin Komissarchik, initial committer of the proposed Eclipse Sappphire UI project.
Sapphire is a newly-proposed Eclipse project that aims to ease
UI development. JAXenter caught up with initial committer
Konstantin Komissarchik to find out how Sapphire fits in with e4,
EMF, and why Oracle is helping to develop Sapphire as an Eclipse
JAXenter: In your opinion, what are the current
pitfalls of writing Java desktop UI?
Konstantin Komissarchik: Regardless of which widget toolkit you
use, the API that the developers are working with are designed to
optimize flexibility and to make as few assumptions as possible.
This is great if you are developing something truly unique, but
much of the UI that is written on the daily basis doesn’t benefit
from this flexibility. In fact, it is hurt by it. Not only does it
take a lot of work to implement simple screens, but consistency is
very difficult to achieve. Developers implement different UI
patterns for solving similar problems. An incredible amount of time
is spent achieving consistency on such mundane items as layout,
button widths and margins.
It’s amazing how much UI code must be written just to present a
text field with a browse button, make sure that data binding
happens and validation problems are surfaced. That code becomes a
product’s maintenance liability. Even the best developers fall into
traps of having UI components talk directly to other UI components.
The resulting web of event handlers will be next to impossible to
maintain and evolve in the future.
On top of that, the code that is written is tied to a particular
widget toolkit. If you want to migrate your app from Swing to
Eclipse RCP, you have to re-write all of the UI from scratch. If
you have a desktop app that you are happy with, but you want to add
a browser-based client you again have to start from scratch.
JAXenter: What are the benefits of replacing a
widget with a property editor in UI, as Sapphire does?
Konstantin Komissarchik: The benefit of
Sapphire‘s approach is that the developer tells
the system what he wants to accomplish rather than how to do it.
Using Sapphire, the developer says “I want to edit LastName
property of the person object.” Using widget toolkit like SWT, the
developer says “create label, create text box, lay them out like
so, configure their settings, setup data binding and so on.”
With Sapphire, similar data patterns will get surfaced in the UI
in a similar manner. Not only that, but the UI definition is
inherently more portable. Since Sapphire doesn’t prescribe the
exact manner in which a given property is to be edited, the
implementer of a renderer can choose an approach that makes the
most sense for the platform they are targeting. The same UI
definition can produce an SWT application for rich desktop
experience and a Web application designed to work in an old browser
under bad network conditions.
JAXenter: How do Sapphire and e4’s declarative
approaches to UI specification, differ?
Konstantin Komissarchik: An e4 UI definition
composes UI out of individual widgets, while a Sapphire UI
definition composes UI out of property editors. Both have their
place. The e4 project will produce the next generation of Eclipse
RCP, with ability to handle arbitrarily-complex UI requirements.
Sapphire will sit on top of that and will provide a higher-level
language appropriate for the majority of situations where
requirements are more mundane.
JAXenter: For Sapphire, why did you opt out of
using EMF as a modeling framework?
Konstantin Komissarchik: We spent a lot of time
debating this internally. In fact, the first attempt was EMF-based.
Ultimately, it came down to ease of use and having a shallow
learning curve. Our goal with Sapphire is to improve how developers
write UI. While our approach centers around a model for the data,
we are fundamentally not in this to promote modeling. It comes down
to doing the best to leverage the knowledge that a typical Java
developer would already poses. We do not want to have learning a
complicated modeling framework to become a barrier to adoption. For
instance, Sapphire’s modeling framework uses Java annotations and
will appear familiar to anyone who has done JAXB or JPA
At the same time, we do not want to exclude developers who are
already invested in EMF from getting the benefits of Sapphire. We
are interested in exploring ways in which Sapphire can leverage
existing EMF models.
JAXenter: The initial code contribution for
Sapphire comes from Oracle’s Enterprise Pack for Eclipse. What is
the motivation for Oracle developing Sapphire as an Eclipse
Konstantin Komissarchik: Multiple motivations
have led to this move. For one, OEPE leverages tooling that comes
from Eclipse projects to create a complete solution for Oracle
customers. If Sapphire is available to these projects, then we
could see even better tooling for standard technologies as projects
become able to produce quality UI quicker. This, of course,
directly benefits Oracle.
We also realize that we cannot by ourselves take Sapphire to its
full potential. For instance, we currently only have a renderer for
SWT. We’d love to work with other members of the Eclipse community
to build a library of quality renderers as that will increase the
value of Sapphire for everyone.