The goal of this specification is to define an API for
common behavior shared by many desktop applications. Most
applications require the following features
* dependency injection via JSR330.
* common application structure.
* application life-cycle.
* localized resources.
* resource injection.
* localized configuration.
* decouple state from UI (binding).
* persistence session state (preferences).
* action management.
* component life-cycle.
* light-weight event bus.
* honor threading concerns (specific to UI toolkit).
* application extensibility via plugins (implies modularity).
There are a good number of framework and platforms that
deliver these features in their own way. Deciding a standard
API for all of them will make it easier to get started with
new projects and fix existing ones. Also, with the rise of
Embedded Java and IoT it makes sense to share codebases
between desktop and embedded projects.
A driving goal behind the JSR is to provide a good
abstraction over common needs of an application regardless of
the toolkit of choice. For example this JSR must deliver an
abstraction on how to access the UI thread (which ever it may
be) and a mechanism for initializing and managing a View
independent of the widget set. The UI thread abstraction has
been already proven true by some of the frameworks mentioned
as source materials.
The set of APIs proposed by this JSR will sit on top of
any UI toolkit without requiring a bridge from a toolkit in
particular; that is, none of the target UI toolkits (Swing,
JavaFX, SWT) need to implement new APIs. If for some reason a
bridge is required it will be provided from the RI side.
This JSR should be released as a standalone one, without
ties to a particular JDK release.