The current status of the RTSJ and JSR 282

The Real-Time Specification for Java (RTSJ) was the first Java Community Process' Java Specification Request (JSR-1). The initial version of the specification was produced in June 2000 in parallel with a Reference Implementation. Inevitably, the completion of the RI showed us bugs and inconsistency. Many of these have been removed in the 1.0.1 version of the specification that was released in August 2004, and the 1.0.2 version of the specification that was released in July 2006 (see www.rtsj.org). However, minor releases such as these are limited to issues that can be construed as bug fixes or clarifications.As commercial products have appeared and user experienced has been accrued, the time is right to consider some of the simpler enhancements that have been requested. These enhancement requests form the basis of JSR 282. They include:1. Add waitForNextRelease() and release() methods to the RealtimeThread class so that 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 the Schedulable interface 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 asynchronous event handlers 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 asynchronous events.13. Permit all errors associated with exceeding RTSJ resource limits to fire asynchronous events (or alternatively, release asynchronous events 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™ 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.The talk will present the current status of these and other developments.