 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 302: Safety Critical JavaTM Technology
JCP version in use: 2.10 Java Specification Participation Agreement version in use: 2.0 Description: This specification creates a J2METM capability, based on the Real-Time Specification for Java (JSR-1), containing minimal features necessary for safety critical systems capable of certification, e.g., DO-178B. Team
The following information has been updated from the original proposal.
2011.03.10: 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.
Specification license (the final license will also use the standard JCP template) Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: The Open Group Name of Contact Person: C. Douglass Locke E-Mail Address: doug.locke Telephone Number: +1 412 977 6003 Fax Number: +1 412 572 3467 Specification Lead: C. Douglass Locke E-Mail Address: doug.locke Telephone Number: +1 412 977 6003 Fax Number: +1 412 572 3467 Initial Expert Group Membership: Aonix Supporting this JSR: Aonix Section 2: Request
2.1 Please describe the proposed Specification:The proposed specification will define those capabilities needed to use Java technology to create safety critical applications. This means that the features included will be a minimal set, with such specific characteristics as static resource allocation and usage, minimal temporal conflicts, and without dynamic loading, leading to the ability to validate implementations using a variety of standards, including DO-178B / ED-12B. It is further implied that the features chosen can be validated using formal models, schedulability analysis, and modified condition/decision coverage (MC/DC) analysis. It is strongly intended that this specification will incorporate the existing Java technology paradigm maximally, subject to the need for application validation. For example, it must be possible to create applications with fully predetermined resource allocation as required by most safety critical standards. This implies, for example, that a garbage collector might not be usable under such standards, and that it might be inappropriate for components to be dynamically loaded. Such applications will likely require a transformation from Java bytecodes to target machine representation prior to certification. It is expected that implementations of this specification will conform to an existing J2ME configuration and profile such as CDC & Foundation Profile, or CLDC & Information Module Profile. Additionally, it is expected that this specification will identify a mechanism for implementations to be constructed for deployment without classes and methods not used by the application so that the DO-178B dead code elimination requirements can be supported. The specification will specifically identify all classes and methods on which a safety critical application can depend at runtime. The Specification Lead, assisted by Expert Group members, will produce a TCK that will fully test the resulting specification. The resulting specification will ensure that all application programs that successfully execute on the Reference Implementation will also execute on any Java platform subject to availability of suitable libraries. It is expected that this JSR will result in a specification such that the International Organization for Standardization (ISO) could later accept it. This JSR has been prepared with the assistance and support of the RTSJ (JSR-1 and JSR-282) Maintenance and Specification Lead (TimeSys Corp). TimeSys is in agreement with the choice of Specification Lead for this effort. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)Embedded (J2ME) 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.This JSR will be based on the J2ME interfaces augmented by the interfaces of the RTSJ (JSR-1) and perhaps including the metadata mechanisms defined by JSR-175, that can be supported within the restrictions of the very stringent resource management constraints imposed on safety critical applications and their supporting standards. While this JSR explicitly targets the J2ME platform, it is expected that applications conforming to the specification developed by this JSR will be able to execute on implementations of J2SETM and J2EETM as well, if the required libraries defined by this JSR are present. Should this JSR be voted on by both Executive Committees?No 2.5 What need of the Java community will be addressed by the proposed specification?Safety critical systems need a certifiable (e.g., DO-178B) Java environment. Certifiability implies hard real-time resource management and generally very small implementations with low complexity. 2.6 Why isn't this need met by existing specifications?The existing J2ME and RTSJ (JSR-1) specifications contain too many functions, and many of their functions are much more complex than can be made certifiable. For example, J2ME and the RTSJ assume the presence of a garbage collector; the proposed specification will not assume the presence of a garbage collector. 2.7 Please give a short description of the underlying technology or technologies:RTSJ (JSR-1), J2ME, possibly JSR-175 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.safetycritical 2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No 2.10 Are there any security issues that cannot be addressed by the current security model?No 2.11 Are there any internationalization or localization issues?No 2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?If this Expert Group determines that the SCSJ differs from a proper subset of the RTSJ, this Expert Group will work closely with the RTSJ (JSR-282) Expert Group to coordinate the changes in the RTSJ. 2.13 Please describe the anticipated schedule for the development of this specification.First meeting: July 31, 2006. 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.Group will meet via teleconference (approximately biweekly), plus occasional personal meetings (approximately 4 per year). The Specification Lead (i.e. The Open Group) will establish the specific rules for Expert Group representation and for reaching decisions. 2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.The Open Group, in line with its normal operating procedures, expects to make the draft specification and most Expert Group activities highly visible to any interested parties. Information about the progress of the specification, RI, and TCK will be made available using the JSR community page, through Open Group mailing lists, and at quarterly Open Group meetings throughout the process. It is expected that comments from interested parties, both JCP members and others, will be forthcoming and will be used by the Expert Group to ensure the usability of the final specification. 2.16 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.stand-alone 2.17 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).Not applicable 2.18 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 freely available. The TCK will be made available under non-discriminatory licensing terms. Pending final arrangements with the organization providing the RI, it is expected that the RI will be available in executable form at zero or low cost with non-discriminatory terms for research use and at low cost with non-discriminatory terms for implementation developers.
Note that this information has been updated from this original proposal.
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.- Ravenscar-Java: A High Integrity Profile for Real-Time Java {University of York) 3.2 Explanation of how these items might be used as a starting point for the work.The Expert Group will review all of these documents to guide their selection of APIs that meet the safety critical requirements. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
