I started reading your blog and the most important question that crossed my
mind, is why you create another binding mechanism when Oracle has just taken
over Sun and Beans Binding ?!
(https://beansbinding.dev.java.net/)

Knowing, there are controversies and even a spin-off at project Kenai.com
(which itself has an uncertain future) does your initiative mean, JSR-195 is
dead?

There are many issues I see, and one not clearly explained is i18n. Myself
and the Eclipse Babel team are happy to assist on that, or even more happy
should Sapphire or a similar project contribute practical i18n and
Globalization support for e.g. XML UI definitions. XWT and E4 claim to do
this by simply building on top of old, but known mechanisms, mainly
PropertyMessageBundles. I
know, Android is among few (Apple and Microsoft follow similar principles,
when it comes to multilingual XML) who use a system similar to
ResourceBundles, but based on XML only (with relevant XML files localized)

The developer community would be happy to hear from Oracle what you have in
mind for Sapphire on that...

> I started reading your blog and the most important question that
> crossed my mind, is why you create another binding mechanism
> when Oracle has just taken over Sun and Beans Binding ?!
> (https://beansbinding.dev.java.net/)

Sapphire hides data binding concepts from the developer. The developer places a property editor on the screen and the framework figures out what controls to render and configures data binding internally. Java Beans Binding is useful when the developer is wiring up data binding manually. It is similar to JFace Data Bindings, except it looks to be limited to the case where source and target are Java Beans, which seems to limit its applicability. For instance, I don't think you could use Java Beans Binding in place of JFace Data Binding to bind to SWT controls.

> Knowing, there are controversies and even a spin-off at project
> Kenai.com (which itself has an uncertain future) does your initiative
> mean, JSR-195 is dead?

I have not followed this project closely (I think you meant JSR-295) and I have no insight on its prospects.

> There are many issues I see, and one not clearly explained is i18n.
> Myself and the Eclipse Babel team are happy to assist on that, or
> even more happy should Sapphire or a similar project contribute
> practical i18n and Globalization support for e.g. XML UI definitions.
> XWT and E4 claim to do this by simply building on top of old, but
> known mechanisms, mainly PropertyMessageBundles. I
> know, Android is among few (Apple and Microsoft follow similar
> principles, when it comes to multilingual XML) who use a system
> similar to ResourceBundles, but based on XML only (with relevant
> XML files localized)

Thanks for the offer of help. I am planning on writing a blog post soon that explains i18n in Sapphire. Stay tuned.

Yes, 295, sorry I get confused by some JSRs sitting around for ages with no
visible progress ;-)

It was said, both it and Swing Application Framework (JSR-296, its direct
"sibling") were at least excluded from Java 7.

Similar to EclipseLink driving parts of Java EE 6 the community may
appreciate Oracle's role towards a binding solution not just limited to
Eclipse and SWT, but let's say at least portable across:
- SWT/XWT
- JSF or RAP
- Swing (assuming it is still a vital part of future Java versions ?;-)
- JavaFX (dito, some say it's doomed, others seem to bet on it)
- some Mobile UI like eRCP

Take MigLayout as an example. It supports Swing, SWT and JavaFX so far,
maybe more which I don't know.