This draft is available for Maintenance Review as per
of the Java Community Process, version 2.1.
- JSR 1 Change Log
The log should be considered together
with the revised specification (at www.rtsj.org), especially the
Changes chapter, which includes the rationale for the API changes.
This change has two parts. The first part, which is the first item in
the change log, is a rewrite of the specification for clarity. That
clarification has resulted in a nearly complete re-write of the
specification, but this change is not intended to express different
semantics. It is intended to express the original semantics:
The deeper motivation for this re-write is that the 1.0 version of the
RTSJ spec is sufficiently ambiguous that it leaves the RTSJ dangerously
open to fragmentation.
- More carefully and completely
- More conveniently (also more redundantly. Some statements
that were made once in the first edition of the RTSJ are now replaced
with the method-by-method consequences of those statements.)
- Without constraining the implementation except where that is
necessary to achieve compatibility between implementations.
The second part of the change is a list of minor API changes. Some of
these changes would appear to break source compatibility with legacy
applications, but these changes are harmless because they modify
aspects of the RTSJ that were initially unusable. We (the authors of
the revised spec) believe that the new APIs leave as much of the RTSJ
working correctly (and as originally intended) as can be accomplished
without making major changes. The deprecated classes are beyond
The first (clarification) part of the changes is compatible with the
current RI and TCK except where the clarification brings out a bug in
the RI or TCK. The second (additional APIs) part of the changes will
require a new release of RI and TCK but we don't anticipate the new
methods requiring much implementation effort.