This web page describes the strengths and weaknesses of Java from the point of view of on-board software (OBS) and the developments in the language that are expected to make it suitable for OBS applications.
The desirable features of an implementation language for OBS are:
OBS applications are usually mission-critical. Software faults can lead to a loss of satellite and indeed software failures are the prime causes of mission faults in space. Hence, a language for OBS has to promote safe coding practices and prevent the use of unsafe constructs. This may be done in three ways: by removing unsafe constructs from the language; by facilitating their recognition through static analysis; by mandating run-time checks to catch errors during executions.
OBS applications are usually subject to hard real-time constraints. A language for OBS must accordingly support RT programming. The level of support can range widely. At a minimum, it must ensure that the code has predictable timing behaviour so that integration with an external operating system providing RT services is possible. At the other extreme, the language should provide built-in synchronization and concurrency facilities that allow RT behaviour to be modelled within the language.
OBS applications are embedded. This means that their code must directly interact with low-level hardware. The programming language must therefore provide facilities to allow access to I/O registers, to raw memory and to interrupt handling routines.
The Object-Oriented (OO) paradigm is now recognized as the one most likely to lead to architectures that are easy to extend, maintain and reuse. A modern language for OBS should accordingly support it.
A wide user base ensures that the support tools for the language are powerful, of good quality, and available at low cost. It also ensures that experiences programmers in the language can be easily found which in turns leads to lower development costs and higher quality code.
Processor resources are often limited in on-board systems. It is therefore desirable that an OBS language be efficient in terms of the run-time and memory overheads that it introduces. This importance of this feature is however less than it used to be in the past thanks to the introduction of space-qualified 32-bits processors.
Not all the above features have the same priority. The essential features are a minimal support for RT programming and for embedded programming. Other features are desirable but can be traded against each other.
Among existing OBS languages, none offers all the features listed here. The two most used OBS languages are Ada and C. Ada has a small user base and its support for OO programming is incomplete [Sch98, Wel00]. C has very limited support for RT programming and does not promote safe coding practices.
Back To Top, Back to Real-Time Java Project Home
The main features of Java that are relevant to OBS applications are:
Java is a very safe languages in the following respects:
- safe memory management model with no explicit pointer types and automatic garbage collection (no danger of dangling pointers and double deletion and minimal danger of memory leaks)
- strong typing model with extensive compile-time and run-time checks to prevent unsafe type conversions
- comprehensive exception handling mechanism with exceptions part of the signature of a method (which forces handling of exceptions) and exceptions modelled as objects (capable of carrying information about the nature of the problem that originated them)
- safe inheritance model that forbids multiple inheritance (a potential source of ambiguity) but allows multiple implementation of interfaces (essential for advanced OO programming)
- support for assertions (from version 1.4)
- run-time checks on array bounds
Note that in respect of all the above points, Java is superior to Ada that is usually regarded as a very safe language and the language of choice for OBS applications.
Java offers only weak support for RT programming. This is the main obstacle to the adoption of Java in OBS and is discussed below.
In order to preserve the Write-Once-Run-Anywhere (WORA) paradigm, Java applications are supposed to interact only with the JVM and the language does not offer facilities to directly manipulate memory, hardware registers or interrupt vectors. This type of operation is however possible through Java's native interface that allows modules written in other languages to be linked with Java. All Java implementations aimed at the embedded market provide proprietary libraries to perform low-level operations.
Java is a fully OO language. It supports all features normally associated to the OO paradigm with the exception of operator overloading and multiple inheritance. These features however are unsafe and not strictly necessary. Their absence in Java is, from the OBS point of view, an asset. In another notable feature, and in an important advantage over Ada95, the Java model of OO is fully integrated with its concurrency model.
Java is arguably the most widely used programming language.
Java applications are traditionally interpreted by a JVM. This creates both memory and run-time overheads. The latter however can be nearly completely removed through the use of ahead-of-time, just-in-time and other dynamic compilation techniques. The memory overhead is significant for small applications (less than 500 kbytes) but vanishes for large applications because Java byte codes are more compact than ordinary assembly language.
The Javadoc facility - which is part of any compliant Java environment - allows user comments in the code to be parsed and automatically used to build a hyperlinked architectural description document.
Java offers the RMI mechanism to allow the creation of distributed object-oriented applications. Its design is modeled after the design of CORBA and, like CORBA, it provides the client object with an illusion of a single address space with the important difference that, unlike CORBA, Java RMI assumes both the client object and the server object to be written in Java. This assumption makes Java RMI programming easier than CORBA programming. and gives more flexibility in the parameter-passing mechanisms which in CORBA are somewhat limited.
Back To Top, Back to Real-Time Java Project Home
An additional weakness of Java for OBS applications is the lack of certified Java tools. This could be a problem where there is a requirement to have a very high quality levels in the OBS code. The issue of certifiability for Java environments does not seem to have yet been tackled. There are persistent rumours ("conference gossip") that use of Java for safety critical applications is being considered but there are no reports of it in the open literature. It is, however, noteworthy that one of the leading solutions proposed for real-time Java – core Java from the J Consortium – appears to be designed with certifiability as a future goal.
Back To Top, Back to Real-Time Java Project Home
Unlike most mainstream languages Java includes a concurrency model. This model, however, stops rather short of supporting hard real-time applications. The Java language was designed to enforce the "write-once-run-anywhere" paradigm or WORA. The need to preserve compatibility with a wide variety of platforms and operating systems severely constrained the specification of the concurrency constructs. Their implementation within the JVM has to rely on services offered by the underlying operating system and the diversity of commercial operating systems is such that ensuring compatibility with all of them inevitably resulted in "weak" specification at Java language level. In fact, many operating systems in common usage – most notably the older versions of Unix – simply do not support real-time operation and would have been a very poor basis upon which to build RT-enabled Java virtual machine. Additionally, Java applications were intended to run in a desktop/workstation environment shared with other (non-real-time) applications. Coexistence of real-time and non-real-time applications can be problematic and this too militated against giving Java real-time capabilities. These constraints resulted in a language that, when seen from the point of view of a real-time programmer, looks under-specified. Most of the basic syntactical constructs that one normally associates with real-time programming – in particular tasking, synchronization and event handling constructs – are present but their semantics is not strong enough to build programs with the level of determinism and timing predictability that is essential in the hard real-time world. Additionally, the presence of the garbage collector and the dynamic nature of the language make static analysis difficult or impossible.
An assessment of the impact of the above shortcomings on on-board systems must start from the consideration that such systems usually have a simplified real-time architecture. Typically, on-board applications are based on cyclical non-preemptive scheduling. In some cases – normally on the payload side or on some experimental frameworks like ESA's OBOSS – fixed priority scheduling with preemption is used but preemption is the exception rather than the rule. Thus, the distance between standard Java and real-time as it is typically used in on-board applications is rather smaller than general discussions of real-time Java would suggest. The table summarizes the main shortcomings of Java for real-time applications and, in the last column, it assess their impact on on-board systems.
| Issue | Problem | Impact for OBS |
| Threading Model | Under-Specification: no guarantees about dispatching policy of ready threads | High: OBS needs a threading
model that allows timing predictability analysis |
| Intra-Thread Synchronization | Missing Feature: no safe means to suspend a thread until a well-defined time in the future | High: cyclical threads require a suspend_until facility |
| Inter-Thread Synchronization | Under-Specification: wait and notify facilities are present but order of release of notified threads is not specified | Low: this type of synchronization is not used in on-board applications |
| Access to Shared Resources | Under-Specification: no priority inversion policy is specified for synchronized methods | Medium: OBS normally do not use pre-emption and hence shared resources |
| Memory Allocation | Under-Specification: memory is allocated from the heap but allocation policy is not specified and could be non-predictable and non-deterministic | Low: in an OBS, memory is allocated only during initialization and never during RT operation |
| Garbage Collection | Under-Specification: garbage collection algorithm and its triggering conditions are not specified and could be non-predictable and non-deterministic | High: even if memory is not allocated dynamically, garbage collection might be triggered at unpredictable times and with unpredictable execution durations |
| HW Interrupt Handling | Missing Feature: no facilities for linking threads or event handlers to hw interrupts | High: handling of low-level hw interrupts important in OBS |
| Asynchronous Event Handling | Under-Specified: standard Java event model adequate if threading model were adequate | Low: asynchronous event handling is not used in OBS |
| Dynamic Class Loading | Incompatibility: dynamic class loading disrupts timing behaviour | Low: dynamic class loading is not required in OBS |
| Class Initialization | Under-Specification: no guarantee about the when classes are initialized | High: untimely initialization can disrupt RT operation and undermining determinism |
Back To Top, Back to Real-Time Java Project Home
Inspection of the table above indicates that most of the inadequacies of Java for hard real-time stem from the weakness of its specifications, itself a consequence of the desire to keep the language compatible with as many operational environments as possible. Thus, one solution to the problem of making Java real-time is simply to develop a Java virtual machine that implements the real-time constructs of the Java language in a manner that allows timing predictability analyses to be performed and hence hard real-time applications to be developed. Consider for instance the problem of thread scheduling. The Java language does not give any guarantee about how threads of different priorities are scheduled. However, the language does not forbid any particular scheduling policy. A JVM developer is therefore free to provide an implementation that enforces a scheduling policy that is suitable for hard real-time applications. The same approach can be followed with all other shortcomings identified in the previous section that are due to under-specification. The result would be a JVM that is compliant with the language specification but that offers some additional guarantees – possibly sufficient to support some of the real-time architectures identified in the previous section.
Three commercial suppliers are currently offering implementations of Java that, to various extents, try to remedy the shortcomings listed above. Esmertec of Switzerland and NewMonics are offering two software-only products whereas aJile is offering a solution based on a chip that implements a JVM in hardware.
Back To Top, Back to Real-Time Java Project Home
Two parallel and competing efforts are currently under way to provide a specification for a real-time extension of Java. One is being carried out under the aegis of Sun's Java Community Process. Its output is the so-called Real Time Specifications for Java or RTSJ [Bol00] which were approved as a formal extension to the Java language in November 2001. The RTSJ are very comprehensive. They cover all the shortcoming of standard Java identified above. An RTSJ-compliant JVM would certainly be capable of supporting the requirement of OBS applications. However, the complexity of the specifications means that availability of such a JVM may require some time (although reference implementations are being offered by both IBM and TimeSys). Time may also be required to clarify ambiguities and to confirm the coverage of the RTSJ. Some early work indicates that both tasks are necessary [Bee01].
The second set of specifications are being elaborated by the J Consortium that brings together a group industry stakeholders that are independent of Sun Microsystems. The J Consortium specifications have not yet been finalized and appear to enjoy less support within the user community. On the other hand, they aim at a more compact run-time system and would therefore be preferable for use in OBS applications both because of the lower demands on on-board resources they place and because they might result in systems that are easier to certify.
As mentioned above, OBS applications only need a small subset of RT constructs. In recognition of this fact, the Ada community has produced the so-called Ravenscar profile [Bur98]. This defines a subset of the Ada language and in particular it limits the RT constructs that can be used in an application. The objective of the Ravenscar profile is to give users as much latitude in the definition of their RT architecture as is compatible with full static predictability of timing behaviour. The Ravenscar profile has been defined with reference to the Ada language but recent work indicates that it can also be implemented in either of the two RT extensions of the Java language [Dob01, Pus01].
The conclusions that can be inferred from recent developments in the RT Java arena are that:
Back To Top, Back to Real-Time Java Project Home
An overview of the intended approach can be found in: The Distributed Real-Time Specification for Java – An Initial Proposal (Jensen E, The Mitre Corporation, 2001). Its focus is on distributed systems defined as systems where there are entities that exhibit trans-node behaviour and where each of these behaviours has end-to-end properties. A distributed system acquires a real-time character when some of these properties relate to timeliness.
The architectural typologies currently used for distributed real-time systems are:
It is of course difficult to predict when the specifications for distributed real-time Java will be ready. The process that is being used to prepare them is the same that was adopted for the RTSJ but started nearly one and half years later. The specifications for real-time Java have just been approved. Hence, assuming that the two specification processes progress at the same rate, one can anticipate that those for the distributed version of real-time Java will be approved in the first half of 2003. As required by the Java community process, approval of the specifications will have to be followed by development of a reference implementation and conformance test suite. In all likelihood, it will therefore be several years before an implementation of Java is available that is both real-time and distributed.
Back To Top, Back to Real-Time Java Project Home
The first issue is in the process of being address. Real-time versions of the language already exist and a real-time specification of the language has been approved. It seems probable that robust RT Java implementation will be available within 1-2 years at most. It should also be noted that the RT requirements of OBS applications are very limited, primarily because preemption is seldom used (or desirable) in OBS applications.
The issue of certifiability is more controversial. Despite recurrent rumours about safety-critical specifications for Java, there is no hard evidence of use of Java in truly safety critical applications. Thus, use of RT Java in OBS applications will probably, at least initially, remain restricted to the less critical systems, primarily in the payload ared.
Back To Top, Back to Real-Time Java Project Home
[Bol00] Bolella G et al, The Real-Time Specification for Java, Addison-Wesley, 2000
[Bro01] Brosgol B, Dobbing B, Can Java Meet its Real-Time Deadlines?, Proceedings of Ada-Europe 2001, LNCS Series Vol. N. 2043, pag. 68-87, Springer-Verlag, 2001
[Bur98] Burns A, Dobbing B, Romanski G, The Ravenscar Tasking Profile for High-Integrity Real-Time Programs, Ada-Europe 1998, LNCS 1411, pag. 263-275, Springer-Verlag, 1998
[Dob01] Dobbing B, The Ravenscar Profile for High-Integrity Java Programs?, Ada Letters, March 2001, N. 1, pag. 56-61
[Nis99] Carnahan L, Requirements for Real-Time Extensions for the Java Platform, NIST Special Publication, Sept.. 1999[Pus01] Puschner P, Wellings A, A Profile for High-Integrity Real-Time Java programs, Proceedings of the 4-th International Symposium on Object-Oriented Real-Time Programming, Los Alamitos, CA, May 2001
[Sch98] Schumacher G, Nebel W, How to avoid the Inheritance Anomaly in Ada, Ada-Europe 1998, LNCS 1411, pag. 53-64, Springer-Verlag, 1998
[Wel00] Wellings A et al, Object-Oriented Programming and Protected Objects in Ada95, Ada-Europe 2000, LNCS 1845, pag. 16-28, Springer-Verlag, 2000
Back To Top, Back to Real-Time Java Project Home