The real-time specification for Java: current status and future work

Abstract

The Real-Time Specification for Java is now about two years old. It has been implemented, formed the basis for research and used in serious applications. Some strengths and weaknesses are becoming clear. This paper reviews the current status of the specification, outlines the challenges ahead and discusses areas where there is likely to be future design work.

A review of the current status of the Java programming on embedded real-time systems

“…RTSJ has defined several guiding principles and requirements for real-time extensions to the Java platform [9][10]. These guiding principles and requirements are high level statements that delimit the scope of the work of the RTJEG (Real-time Java Expert Group) and introduce compatibility requirements for The Real-Time Specification for Java:…”

Refactoring Asynchronous Event Handling in the Real-Time Specification for Java

“…An example application requirement might be to execute an interrupt handler. Here, the fired() method may invoke the run() method directly rather than by a server thread without entailing unnecessary operations which take place in the standard AsyncEventHandler such as queuing and waiting to be scheduled in competition with other activities [4]. • It can provide its own version of the Handler class should the need arise.…”

Model-based verification of a framework for flexible scheduling in the real-time specification for Java

“…The system_ceiling[][] array keeps a stack of the system ceiling in row 0 (system_ceiling[0][]), while in row 1 it keeps the thread that has locked the corresponding resource. mutex is used between the Thread and BaseScheduler automata and contains the ceiling of the resource to be locked or unlocked and the corresponding band for that ceiling, in the format xxxy, where xxx is the ceiling and y is the low priority of the band (this clearly only works for bands with a low priority of 1 to 9 but its enough for the purposes of our model will be locked first, then threadx_resources [1] will be locked in a nested way, and so on. The number of resources actually locked in each run is random, so we are not specifying one particular scenario through the use of this array.…”

“…The RTSJ ( [1], [2]) provides a framework from within which realtime scheduling can be performed for single-processor systems. The intention is to support a range of schedulers, all of them conforming to the abstract Scheduler class.…”