 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 377: Desktop|Embedded Application API
JCP version in use: 2.11 Java Specification Participation Agreement version in use: 2.0 Description: The purpose of this specification is to standardize common behavior found in desktop & embedded applications Expert Group Transparency: Public Project Page Public Communications Issue Tracking Team
This JSR has been Dormant The following changes have been made to the original proposal:
2019.05.09: Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Almiray, Andres Name of Contact Person: Andres Almiray E-Mail Address: aalmiray Telephone Number: +41 789 422 340 Fax Number: +41 612 289 449 Specification Lead Member: Andres Almiray Specification Leads: Andres Almiray E-Mail Address: aalmiray Telephone Number: +41 789 422 340 Fax Number: +41 612 289 449 Initial Expert Group Membership: - Mohamed Taman Supporting this JSR:
Canoo Enginnering AG : Hendrik Ebbers 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. 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?No. 2.9 Are there any security issues that cannot be addressed by the current security model?No. 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 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?
- Can the public read and/or write to a wiki for the JSR?
- Is there a publicly accessible discussion board for the JSR that you
read and respond to regularly?
- Have you spoken at conferences and events about the JSR recently?
- 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?
- 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.
- What is the mechanism for the public to provide feedback on your JSR?
- 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?
- 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)? 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).N/A 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 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?https://github.com/jsr377/jsr377-api/issues 2.20 Please provide the location of the publicly accessible document archive you have created for the Expert Group.https://github.com/jsr377/jsr377-api/releases 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)
* http://new.griffon-framework.org 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 InformationThe following links describe the rationale for proposing this JSR http://www.jroller.com/aalmiray/entry/it_s_time_for_a http://www.jroller.com/aalmiray/entry/new_desktop_application_framework_jsr
Additionally the following presentation was posted to the JCP EC meeting on Nov 9 2014: http://www.jroller.com/aalmiray/entry/it_s_time_for_a http://www.jroller.com/aalmiray/entry/new_desktop_application_framework_jsr |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
