Goals of Project Wonka

The aim of the project is to create an implementation of JavaTM, the Open Services Gateway (OSG), and the Open Telematics Framework, suitable for use in embedded systems. This must be a complete and correct implementation, readily portable to a wide range of devices, characterised by a high level of availability, usable in systems which have real-time requirements, and it must make efficient use of limited resources.

Wonka should be the VM of choice for embedding Java in consumer products.

Complete and Correct

Everything we claim to implement must be there, and must work according to spec.

For the VM itself, this means complete adherence to the JavaTM Virtual Machine Specification, 2nd Ed.. For the standard class libraries, the scope is determined by the published profile and the functionality by The JavaTM Class Libraries, 2nd Ed..

In a few isolated cases, we may diverge from the specification in order to be "bug-compatible" with Sun's own implementation. These cases should be documented and kept under review (it is impossible to tell whether the difference is due to an undocumented change to the specification or to an error which will be corrected in the next JDK release).

Portability

Keep it clean.

Porting the implementation to a new environment must be a straightforward operation, and should result in a high degree of confidence that the ported version will function correctly. The keys to portability are well-defined interfaces and clean code.

The interface to the memory management and scheduling functions is defined in rtos.h. Avoid making direct calls to functions of a particular [RT]OS, even "universal" functions such as malloc() or free(): on some platforms we might need to make wrapper functions, e.g. because the standard malloc() is not thread-safe. Interfaces to physical devices must be isolated either by packaging them in JNI libraries or by using the Virtual Device Interface defined in vdi.h.

We only allow the following deviations from ANSI C:

The ANS standard allows compilers to implement the standard data types char, int, long, etc. in different ways; therefore the data types w_char, w_int etc. should always be used. We assume that a C pointer (e.g. void *) fits into a w_word, because this is pretty well hard-wired into the Java language. Apart from that, nothing should be assumed beyond the letter of the ANSI standard. Ill-defined constructs such as bitfields must be avoided, as must non-standard features or "extensions" to standard library functions, however seductive.

High Availabilty

24/7/365/1000

The system should be capable of running "forever", without degradation of performance. That means that leakage of memory or other resources is simply unacceptable, as are "rare" race conditions or other causes of unpredictable behaviour. It also means that data structures and algorithms should be designed to tend to an acceptable steady state over time, without the need for major maintenance.

Real-time Friendly

As real-time as its environment allows

We don't really expect the most time-critical parts of an embedded system to be implemented using Java. However it must be possible to use the JVM in systems where there are real-time requirements, and for subsystems which use Java to have predictable response times. Some consequences ot this are:

Efficient

A question of balance

Efficiency is the ratio of output produced to resources consumed. Time is an important resource, but it is not the only one: other resources such as memory and communications bandwidth can also be important. A system can be called efficient when it succeeds in balancing its use of resources to obtain an optimal result.