Find JSRs
Submit this Search

Ad Banner

JSRs: Java Specification Requests
JSR 377: Desktop|Embedded Application API

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Almiray, Andres

Name of Contact Person: Andres Almiray

E-Mail Address:

Telephone Number: +41 789 422 340

Fax Number: +41 612 289 449

Specification Lead Member: Andres Almiray

Specification Leads: Andres Almiray

E-Mail Address:

Telephone Number: +41 789 422 340

Fax Number: +41 612 289 449

Initial Expert Group Membership:

- Mohamed Taman
- Rajmahendra Hedge
- Johan Voss

Supporting this JSR:

Canoo Enginnering AG : Hendrik Ebbers
JUG Hyderabad : Rajmahendra Hedge
Morocco JUG : Mohamed Taman
Logdon : Johan Voss
Credit Suisse : Anatole Tresch
NeatBeans Dream Team : Sven Reimers
Oracle : Gerrit Grunwald
Oracle: Jim Weaver
Oracle: Geertjan Wielenga
Tom Schindl
Carl Dea
Tom Costella
Sebastien Bordes
Alan Williamson

Section 2: Request

2.1 Please describe the proposed Specification:

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.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

The target platforms are desktop and embedded where Java SE can run. This JSR does not target ME due to the inherent limitations of the platform nor EE as there are already a good number of JSRs that target it.

2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.

The target platform is Java SE, lower bound being Java7 thought Java8 may be considered as the basis given: a) rate of adoption for Java8 by target market OR b) Java8 features help in designing a better API.

2.4 What need of the Java community will be addressed by the proposed specification?

This work will address the need of the Java community for a simplified programming model for desktop applications. In particular, this model is suited to rapid development of MVC applications.

2.5 Why isn't this need met by existing specifications?

There's no specification that can target desktop and embedded applications at the moment. The previous attempts (JSRs 193 and 296) did not make it to their final release and were too limited in their goals.

2.6 Please give a short description of the underlying technology or technologies:

The goals of this work may in principle be met by implementing an API on top of existing technology in Java SE and existing JSRs such as JSR-330.

2.7 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

Not known at this time.

2.8 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?


2.9 Are there any security issues that cannot be addressed by the current security model?


2.10 Are there any internationalization or localization issues?

Internationalizable resources that can be consumed by an application are one of the concerns of this specification.

2.11 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No. This specification builds upon existing APIs.

2.12 Please describe the anticipated schedule for the development of this specification.

The following dates are preliminary:

Expert Group Formation: January 2015
Early Draft Review: May 2015
Public Review: September 2015
Final Release: December 2015

2.13 Please describe the anticipated working model for the Expert Group working on developing this specification.

The primary means of communication will be email, with conference calls and face-to-face meetings scheduled as needed. We will solicit feedback from the community and leverage the open source development model.

2.14 Provide detailed answers to the transparency checklist, making sure to include URLs as appropriate:

- Is the schedule for the JSR publicly available, current, and updated regularly?
We'll begin in January 2015. The schedule will be posted at for everyone to see

- Can the public read and/or write to a wiki for the JSR?
See above.

- Is there a publicly accessible discussion board for the JSR that you read and respond to regularly?
Yes. The initial forum is located at

- Have you spoken at conferences and events about the JSR recently?
Yes. I've mentioned this topic in several conferences since Aug 2014 (JCrete, JavaOne, Geecon CZ and Devoxx BE).

- Are you using open-source processes for the development of the RI and/or the TCK?

- What are the Terms of Use required to use the collaboration tools you have prepared to use with the Expert Group, so that prospective EG members can judge whether they are compatible with the JSPA?
GitHub Terms of Service

- What is the location of your publicly-accessible Issue list? In order to enable EC members to judge whether Issues have been adequately addressed, the list must make a clear distinction between Issues that are still open, Issues that have been deferred, and those that are closed, and must indicate the reason for any change of state.
For the API:
For the TCK:
Will post an update for the RI once the EG has decided how to tackle it (create new project or use an existing one).

- What is the mechanism for the public to provide feedback on your JSR?
Direct communication via mailing list, issue tracker, wiki, twitter, Hackergarten meetings.

- Where is the publicly-accessible document archive for your Expert Group?

- Does the Community tab for my JSR have links to and information about all public communication mechanisms and sites for the development of my JSR?
We intend this to be the case.

- Do you have a Twitter account or other social networking feed which people can follow for updates on your JSR?

- Which specific areas of feedback should interested community members (such as the Adopt-a-JSR program) provide to improve the JSR (please also post this to your Community tab)?
We are interested in all feedback we can get from the community.

2.15 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

The reference implementation will be made available standalone. The TCK will be made available standalone as well.

2.16 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).


2.17 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

* The specification will be licensed using the standard specification license
* The RI and TCK will be licensed via the Apache License 2.0

2.18 Please describe the communications channel you have established for the public to observe Expert Group deliberations, provide feedback, and view archives of all Expert Group communications.

Public can observe EG deliberation on mailing list and issue tracker.

2.19 What is the URL of the Issue Tracker that the public can read, and how does the public log issues in the Issue Tracker?

2.20 Please provide the location of the publicly accessible document archive you have created for the Expert Group.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

The following frameworks/platforms will be used as inspiration and source material (as permited by their licensing model)


3.2 Explanation of how these items might be used as a starting point for the work.

These frameworks provide many of the features that this specification targets for standardization.

Section 4: Additional Information

4.1: Additional Information

The following links describe the rationale for proposing this JSR

Additionally the following presentation was posted to the JCP EC meeting on Nov 9 2014:
Presentation to the Executive Committee on JSR 377 (9 November 2014)