These notes introduce the Draft API for Safety
Critical Java (subset of RTSJ and J2SE) produced in July 2004. The
draft API specification is presented in javadoc format.
Here are some clarifications
and explanations:
1.
The Beta JDK
1.5
compiler was used to compile all of the API code and to produce the javadoc.
At the time of its preparation, tools to validate
consistency of the meta-data annotations were not available.
The intent is that a safety-critical Java byte-code verifier would
subseqeuently provide this consistency checking.
2.
A few problems with the JDK 1.5 javadoc tool affected the resultant
specification which was produced. In particular:
a) Annotations associated with
parameters are not being displayed, and
b) Annotations associated with
constructors are not being displayed.
For both of these
shortcomings, the author inserted redundant comments into the corresponding javadoc
commentary.
Another shortcoming of the 1.5 beta software was that mif-doclet has not yet been released.
3.
At the time of its preparation and publication, the resulting specification was
not extensively reviewed. As a result,
there are likely to be
errors and/or inconsistencies in this draft API specification.
More detail is needed in many
descriptions, especially those of the java.lang package.
The API described in this specification is proposed to represent the
API for the entire safety-critical Java platform.
Any library not described here is not "generally" available to
safety-critical developers.
Individual vendors are
free
to supplement the platform with additional libraries if they choose to do so,
but those additional libraries should be clearly distinguished from the
"standard platform".
4. A careful reader of
the
draft spec raised the following question: In each of the following code
fragments, what method(s) does the InvocationMode apply to
assert
StaticLimit.InvocationMode(MyMode);
x =3D y ? foo() : bar() + zot();
assert
StaticLimit.InvocationMode(YourMode);
x =3D foo(bar(), zot());
This needs to be
clarified. A proposed resolution is to adopt the position that
the effects of each InvocationMode assertion endure until a subsequent
contradictory InvocationMode assertion.
5. The same careful reader
says: "It bothers me that some of the StaticLimit assertions apply to
the
next statement (e.g. InvocationMode) while others apply to the previous
statment (e.g. ArrayLength).
This
seems like an easy source of programmer errors." There is "good rationale" for
the way things are currently specified, with perhaps a need for a better
explanation in the specifcation.
----
Kelvin Nilsen, Ph.D.
Chief Technology Officer for Java, Atego
