On the development of the Real-Time Specification for Java - Embedded.com

On the development of the Real-Time Specification for Java

An interview with Doug Locke, vice president of technology at TimeSys and member of the Real Time Java Expert Group, about the real-time Java standard and the differences between the Java Community Process and the IEEE.

Although the creators of the Java programming language had embedded systems in mind as a platform from the start, the language morphed into something much larger and less deterministic as it was adopted by Web developers. Those changes, most of which took place in the language's first three years of life, diminished Java's appeal as a real-time programming language.

However, Java does have some nice features for embedded programmers-features that make it a potentially better language than C and C++ or even Ada. As a result, many in the real-time community became interested in enhancing Java with better determinism and multithreading. There was some speculation that the IEEE might become involved, but it was ultimately decided to use Sun's Java Community Process (JCP). A Real-Time Java Expert Group was formed through the JCP in late 1998 and the resulting specification was released about three years later.

Michael Barr met with Doug Locke at the Embedded Systems Conference in Boston. Locke was a member of the Real-Time Java Expert Group that defined the RTSJ. He was also once a member of the IEEE Working Group that defined the 1003.1b and 1003.1c standards for real-time extensions to POSIX.

Michael Barr: In a nutshell, how does the JCP standardization process differ from the IEEE process?

Doug Locke: There are many differences, but there are two that I believe are most significant. First, IEEE standards are generally written by working groups composed of anyone who wishes to volunteer, usually IEEE members. The working group members are not assumed to be representing the organizations from which they come. The JCP specifications are written by a Specification Lead assisted by an Expert Group chosen by the Specification Lead. Participants are organizations, each represented by an individual. This means that an IEEE working group will frequently have new members, while the JCP Expert Group membership will generally be static. In an IEEE working group, if a member changes employers, his/her membership will not necessarily change. In a JCP Expert Group, if a member changes jobs, a replacement will generally be found by the organization represented.

The second significant difference is that an IEEE standard is completed only when a balloting group, formed independently from the working group (although most working group members will also be members of the balloting group), has ratified it with at least 75% agreement. A JCP specification is complete when the Expert Group finishes it, a Reference Implementation has been completed, a Technology Compatibility Kit (test suite) has been completed, and the JCP Executive Committee has approved it. This means that the likelihood of widespread community agreement with an IEEE standard is significantly higher than that of a JCP specification. On the other hand, the time required to complete a JCP specification is MUCH shorter than the time required to complete an IEEE standard. In addition, the requirement for a completed RI and TCK before completing the specification means that there will be little doubt of the implementability or usability of the specification.

Michael: Do you feel that the JCP process allowed the real-time Java expert group to reach a reasonable standard in a reasonable amount of time?

Doug: Yes, in my opinion the JCP process definitely worked well in this case. It took almost 3 years to complete the RTSJ. In contrast, it took about 7 years to complete the process-level and thread-level real-time extensions to the IEEE POSIX standard (called 1003.1b and 1003.1c). One might argue that the RTSJ was easier because it made use of the POSIX standard by reference, but it can also be argued that the RTSJ was more complete, providing, for example, flexible scheduling extensions and asynchronous transfer of control. It should also be observed that the RTSJ Specification Lead representative changed employment during this period. In my opinion, the resulting adjustments probably resulted in a delay. Even so, in addition to the RI, a complete commercial implementation from TimeSys is almost ready and several other commercial and academic implementation efforts are under development.

I should also note that many of us feel that the RTSJ (JSR-000001 under the JCP) is probably the most ambitious specification likely ever to be produced under the JCP. It calls for a rewritten or extensively modified Java Virtual Machine, with greatly extended semantics for frequently used Java mechanisms such as object creation and thread management.

Michael: Are you completely happy with the RTSJ standard that resulted?

Doug: Every standard consists of a set of compromises. The RTSJ is certainly not perfect, and a clarification update is currently underway to improve its accessibility. It can be expected that further revision will be performed several times over the next few years.

However, the RTSJ does accomplish exactly what it promised, providing concrete, workable solutions to all of the critical issues inherent in using the Java technology in embedded and real-time systems. This includes memory allocation, thread management, scheduling, event processing, clock and timer precision, and asynchronous transfer of control.

Overall, I'm quite happy with the RTSJ.

Michael: Was pressure exerted on the group (by Sun or another outsider) to reach any particular decision?

Doug: Sun exerted no stronger pressure than any of the other organizations represented in the Expert Group. Many of the decisions made represented strongly held opinions by one or more of the Expert Group members; this was true for Sun as well as for IBM and each of the other members. Examples of a few of these strongly-held opinions that guided the RTSJ development are:

  • The RTSJ should not require a modified Java compiler. This means that the Java language itself should not be modified or have new keywords.
  • The RTSJ should enable true real-time, deterministic implementations, but it need not absolutely require them.
  • An RTSJ implementation can be expected to run best either stand-alone or on an RTOS, but it should also be possible for a compliant implementation to run on a general-purpose OS. The marketplace, not the RTSJ, should determine what resulting performance level is acceptable for each application domain.

Each of these decisions, and many others, necessitated compromises that are reflected in the specification.

Michael: There was an issue during the RTSJ standardization process where the expert group's lead changed jobs and employers. How did that change affect the work of the group as a whole? Did it slow things down?

Doug: About halfway through the RTSJ development, after the initial release of the specification, Dr. Greg Bollella of IBM decided to leave IBM and accepted a position at Sun. At that time, IBM chose Peter Haggar to take over the RTSJ leadership, and Sun assigned Greg to represent them on the Expert Group in place of James Gosling. This change, in itself, did not have a major effect on the RTSJ development; Greg continued in an active role, and Peter Haggar's leadership did not change the prior direction of the group in any major way.

However, because the lead is typically responsible for the reference implementation (RI), the change did result in some deliberation within the Expert Group regarding who would proceed with the construction of the RI and TCK. Because of the breadth of the RTSJ, its RI represented a complex effort with a significant expenditure of resources. TimeSys agreed to take a leadership role in developing the RI, and the effort continued to a successful conclusion. I feel that this issue would probably have been resolved somewhat faster if the leadership change had not been necessary.

Michael: The JCP process has a proven track record for establishing new standards in a fraction of the time that the IEEE process does. From your viewpoint, are faster standards a good thing or a bad thing?

Doug: Minor note: I do not use the word “standard” when the effort is not sanctioned by an accredited standards organization such as ANSI or IEEE. The JCP is an example of a consortium-based approach to producing a “specification” in which a collection of organizations, mostly profit-driven, agree to pool their effort to produce something they can all agree on. Another example of a consortium-based approach is the Object Management Group that produced the CORBA (and Real-Time CORBA) specification.

As you have observed, consortia can produce specifications more quickly than accredited standards organizations. I do, indeed, think that faster “standards” are a good thing, but we must remain aware of the attendant risks. First, the level of community agreement resulting from a consortium-based specification is not as high as for a standard, so there is a higher probability that the resulting specification will not lead to successful, widely used commercial implementations. Second, it is more likely that competing specifications in the same domain will be produced by competing consortia; this is much less likely when the effort is done by an accredited standards organization.

However, these risks can be mitigated (not eliminated) by keeping the process as open as possible, inviting the maximum possible amount of feedback from the community, and keeping an open dialog with as many related efforts as possible. For example, in the case of the RTSJ, Greg Bollella, myself, and others have spent considerable amounts of time on panels and other open forums with many other people keeping the RTSJ constituency informed and airing both supporting and opposing views. Additionally, Greg arranged for the RTSJ draft to be published by Addison Wesley and it was very widely disseminated. Finally, the RI has been downloaded from the TimeSys website by over 2000 people to date, inviting feedback from a large population of Java developers.

Michael: It sounds like you think the JCP process is pretty effective. What suggestions do you have, if any, for improving it?

Doug: Generally, I believe the JCP is working well. The only serious deficiency I have observed to the current JCP process is related to the final approval process when the entire specification, RI, and TCK have been completed. At this point, the relevant JCP Executive Committee has the responsibility to review the entire package and approve or disapprove it. The problem is that if the Executive Committee disapproves it for any reason, the Expert Group has only 30 days to fix whatever issues are found.

In my opinion, this short fix period means that a major effort and expenditure of resources can be lost just because of a few dissenting voices who may not have been actively involved in developing the specification. I believe the time limit should be left to the Expert Group or Specification Lead to determine, based on their assessment of the work involved and likelihood of success. Abandoning the effort, in my opinion, should be a decision of the Expert Group, not the Executive Committee.

That said, following the forced abandonment of a few JSR's due to this rule, it appears that both the Expert Groups and the Executive Committee are better coordinating this final approval process so it is less likely to be unsuccessful without warning.

RESOURCES

Douglass Locke , Vice President of Technology of TimeSys Corporation, has spent more than 35 years intimately involved in the specification, architecture, design, and implementation of a wide range of time-critical systems. Doug has served and continues to serve on various standardization committees related to real-time, including POSIX, Real-Time CORBA, Real-Time UML and the Real-Time Specification for Java. He holds a PhD in Computer Science from Carnegie Mellon University.

Michael Barr is the editor in chief of Embedded Systems Programming. He is a lecturer at the University of Maryland and author of Programming Embedded Systems in C and C++ (O'Reilly). Contact him by e-mail at .

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.