The Java Community Process(SM) Program - JSRs: Java Specification Requests - detail JSR# 282

Find JSRs

• JSRs by Platform
• JSRs by Technology
• JSRs by Stage
• JSRs by Committee
• List of All JSRs
My JCP
Register for Site
Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy
JCP Info
• About JCP
  • Program Overview
  • JCP Process Document
  • Calendar
  • JCP Members
  • Executive Committee
  • Elections
• Get Involved
  • Overview
  • Becoming a JCP Member
  • Java in Education
• Community Resources
  • Overview
  • Tutorials
  • JCP Podcasts
  • Spec Lead Guide
  • TCK Tool & Info
  • License Reference
• Community News
  • News
  • Programs & Awards
  • Press Releases
  • Success Stories
• FAQ
• Contact Us

Status: Final
JCP version in use: 2.11
Java Specification Participation Agreement version in use: 2.0


Description:
Fill some minor gaps in the RTSJ

Expert Group Transparency:
Public Project Page
Public Communications
Issue Tracking

Updates to the Original JSR

The following has been changed from the original proposal:

2023年04月27日:
The JSR has been listed as "Inactive" because it has not published a Final Release and it has been more than 12 months since the last milestone was posted.

2019年11月05日:
The title of the JSR - "RTSJ version 1.1" was updated to "RTSJ version 2.0" to reflect the current version.

2019年07月17日:

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 and TCK licenses
RI license

2019年05月31日:
JSR 282 moved to JCP 2.11.

2017年02月03日:
JSR 282 moved to JCP 2.10.

2014年08月04日:
The Specification Lead provided the following transparency information:

* How will you consult with the existing Expert Group on any new EG nominations?

All nominations are discussed with the active members in our weekly teleconferences.

* How will you provide details of new EG nominations to the public?

There is now a new page for updates to JSR282:
https://www.aicas.com/cms/en/rtsj.

* What is the URL of the archive of public Expert Group communications? What is the URL of the Expert Group's document archive? Is the schedule for the JSR publicly available, current, and updated regularly?

This will be on the new rtsj page.

* Is there a publicly accessible discussion board for the JSR that you read and respond to regularly?

https://www.linkedin.com/groups/8147216/

* Have you spoken at conferences and events about the JSR recently?

I present the current state of the RTSJ at every JTRES conference and it the Open Group Embedded Forum approx. once a quarter, but at least every six months.

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

No.

* What are the Terms of Use required to use the collaboration tools you have prepared to use with the Expert Group?

LinkedIn terms of use
WebEx terms of use.

* What is the location of your publicly-accessible Issue list?

We maintain an issue list on the JSR-282 web page.

* What is the mechanism for the public to provide feedback on your JSR?

There is a mailing list for this: "jsr282-feedback@aicas.com".

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

This will be kept on the RTSJ site.

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

I will post updates to realtimejava on Twitter with the hash tag #RTSJ.

* Which specific areas of feedback should interested community members (such as the Adopt-a-JSR program) provide to improve the JSR?

The original RTSJ spec had many places where the specification was not sufficiently clear. Contributions to identifying and proposing solutions to such places would be very helpful.

2012年10月23日:
Aicas GmbH has become the Specification Lead.

Specification Lead: Dr. James Hunt, Aicas GmbH

E-Mail Address: jjh@aicas.de

Telephone Number: -

Fax Number: -

---

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: TimeSys Corporation

Name of Contact Person: Peter Dibble

E-Mail Address: peter.dibble@timesys.com

Telephone Number: +1 412 325 6346

Fax Number: +1 412 232 9819

Specification Lead: (削除) Peter Dibble (削除ここまで)

E-Mail Address: (削除) peter.dibble@timesys.com (削除ここまで)

Telephone Number: (削除) +1 412 325 6346 (削除ここまで)

Fax Number: (削除) +1 412 232 9819 (削除ここまで)

Note that the Specification Lead has changed from this original proposal.

Initial Expert Group Membership:

David Holmes
IBM
Sun Microsystems, Inc
Andy Wellings

Supporting this JSR:

Sun Microsystems, Inc

Section 2: Request

2.1 Please describe the proposed Specification:

This proposal addresses some of the simpler enhancements that have been requested in the RTSJ:

1. Add waitForNextRelease() and release() to RealtimeThread so real-time threads will be better able to handle aperiodic processing.
2. Investigate a class, similar to the weak reference classes, that supports references between memory areas that would normally be forbidden by the RTSJ assignment rules.
3. Relax the ?bi-directional reference rule? for parameter objects.
4. Add new methods in the Timed and Timer classes to more easily support both start relative to now and start relative to the original start time, for reset and reschedule.
5. Add a form of Timed.reset() that resets the timeout for the current execution.
6. Add new methods to query the state of Timers and real-time threads.
7. Add a method to Schedulable and processing group parameters, that will return the elapsed CPU time for that schedulable (if the implementation supports CPU time)
8. Add an option for AEH that will cause the AEH?s memory area to be entered each time the AEH invokes handleAsyncEvent()
9. Consider a method that determines whether there is more than one reference to an object. (To better support ?recycling lists?)
10. Add a blocking factor value to ReleaseParameters to support better feasibility analysis
11. Review the current support for real-time garbage collectors, and expand it if necessary.
12. Associate a scheduling eligibility value with async events.
13. Permit all errors associated with exceeding RTSJ resource limits to fire async events (or alternatively, release async event handlers). Currently some of them can only throw exceptions.
14. Add new methods as necessary to consistently provide both a method that creates a returned object and one that takes a destination wherever those forms are appropriate.
15. Update the documentation for the physical memory classes to improve their clarity. Make the minimum modifications to the semantics and APIs required to fix any problems that justify such changes.
16. Update the semantics for cost enforcement to permit support of the invariant that a schedulable's CPU use in each period is bounded by the cost.
17. Consider compatible modifications to the RTSJ that would make it easier to limit the use of immortal memory.
18. Modify the specification as required to clarify any interaction with Java^TM 5.
19. Consider hierarchical processing group parameters.
20. Consider improvements to the wait-free queue classes, or possibly new classes with similar services.
21. Consider enhancements to the async event system to let events carry data.

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

RTSJ (JSR-1) explicitly targets all Java platforms, but the primary target as represented by the reference implementation is embedded platforms (Java ME/CDC). The proposed revision will continue the policy of implementing for Java ME, but will be designed to be implementable on other Java platforms, especially Java SE.

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 proposed specification will focus primarily on Java ME/CDC, but will inherit from JSR-1 the requirement to remain compatible with other platforms.

2.4 Should this JSR be voted on by both Executive Committees?

Just the ME committee

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

This JSR would address loose ends from JSR-1 that are too large to be incorporated in a minor revision, but small enough to be specified and implemented relatively easily. This is an early step in the evolution of the RTSJ. Other enhancements are needed, but this incremental approach will give the community access to needed improvements more quickly than a more comprehensive JSR.

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

Some of the problems addressed by this JSR could be seen as defects in JSR-1. Others are facilities for which the need was not understood until the RTSJ was in regular use.

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

The technology of the RTSJ. This is a specification that extends the Java platform to make it better suited to real-time applications.

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

javax.realtime

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

It would be difficult to implement RTSJ on a platform that does not support real-time applications. In this respect, this specification does not represent a change from JSR 1.

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?

RTSJ 1.0.1

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

After formation of the expert group, we would expect to use six to nine months to write the specification. The RI and TCK would be evolved from the existing RTSJ RI and TCK, so their generation should not take more than a few months. Leaving time for the review cycle, we might be able to finish in less than year.

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

The Expert Group will be located in at least 3 widely separated time zones, so email will be its primary communication mechanism, supplemented by conference calls as necessary. Experts may focus on one or more functional areas of the specification with the spec lead taking over-all responsibility. Decisions will be made by the Specification Lead based on Expert Group consensus to the greatest extent possible.

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.

Interim versions of the specification will be posted, as will summaries of substantive discussions that the Spec Lead think deserve broader exposure.

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.

The RI must be a fully functioning JVM, so it will be delivered as a specialized superset of Java ME (specifically based upon CVM 1.0 as the current RTSJ RI is delivered.)

The TCK will continue to be stand-alone, and will only verify that RTSJ functionality is present and complies with the specification. The Java compliance of the other aspects of the platform are the province of other TCKs.

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).

There is no change.

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 downloadable (under an appropriate license), for both research and commercial use related to the development of compliant products and products compatible with compliant products. Any conforming implementation may distribute with the implementation a javadoc-HTML version of the specification. This may include added text as required to fulfill the RTSJ documentation requirements. There will be no fees associated with such use of the specification.

The RI binary will be freely downloadable under reasonable and non-discriminatory license terms for non-commercial (research-only) use. There will be no fees required for research use of the RI binary.

The TCK will be freely available in binary form under reasonable and non-discriminatory license terms for non-commercial (research-only) use. There will be no fees required for research use of the TCK. Commercial use and source access for the TCK will be permitted under reasonable and non-discriminatory commercial licensing terms and will be fee-based.

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.

RTSJ 1.0.1 at www.rtsj.org

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

Since this JSR represents evolutionary progress of the RTSJ, the existing specification must form the basis of this work.