This draft is available for Maintenance Review as per 4.2 of the Java Community Process, version 2.1.

Comments to: peter.dibble@timesys.com

• 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:
  • ������ 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 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.

  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 repair.

  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.