Future requirements for JavaOS
The following interview was conducted electronically with Bernard Mushinsky, president of IPI, on June 12, 1996. Thinking that Java was going to have a negative effect on his business, we asked Bernie some questions and were happy to learn that Java is creating opportunity in markets where it can potentially displace some well-developed technologies. A short discussion of the newly announced JavaOS from Sun Microsystems and some pointers to other, related sites follow this interview. JavaSoft has also announced plans for an embedded API and serious developers should check out the general status of all the APIs.
Interview
Rinaldo: What is IPI and what does IPI do in the real-time industry?
Bernard: IPI’s MTOS is a family of real-time operating systems that are widely used in embedded applications. There are more than two thousand licensees; many thousands of MTOS-based products have been developed. There are literally millions of embedded copies of MTOS in action in the real world.
MTOS ports are available for the 80×86 and 68xxx families, the MIPS R3000/R4000, and the PowerPC. Numerous board support packages have been developed and are readily available to interested parties. Among these is a highly integrated system for the 80×86-based PC. This system takes over the PC, and includes a DOS-compatible file system and drivers for all of the standard PC peripherals. Part of the standard package includes extensive support for third-party development and debugging software, as well as IPI’s own Debugger/Resource Reporter.
MTOS applications range from a device to mix drinks to the AWACS and other high-end products. A few of the main product areas and some typical customers are listed below.
| Communication Systems | Alcatel, Ericsson, Fujitsu, GPT, GTE, Motorola, NTT, Philips, Tellabs |
| Process Control | ABB, Bristol Babcock, Bailey, GE, Honeywell, Measurex, Toshiba |
| Factory Automation | GE, GM, Mitsubishi, Philips, Sony, Toyota |
| Medical Equipment | Ciba/Corning, Cobe, Gambro, GEC, Johnson & Johnson, Nova Biomedical, Puritan Bennett, Siemens |
| Graphics & Imaging | Data Products, Genicom, IBM, Kodak, Philips, Printronix |
Rinaldo: What will the effect of Java be on IPI’s business? How do you think the picoJava, microJava, and UltraJava chips will effect your industry?
Bernard: In order to answer this question, it’s necessary to assume that Java will evolve rapidly into a system that can meet the needs of the embedded systems marketplace. I say rapidly because, if the evolution is too slow, then Java really won’t get there at all. Furthermore, while Java, as presently constituted, can be used in certain non-critical embedded applications, it needs to be strengthened in significant ways. It should be more efficient, more robust, and more capable in ways that are relevant for embedded applications. One of the really undesirable things that should be avoided at almost any cost is a proliferation of proprietary solutions. Really, Sun should face up to these issues and, perhaps by working with a company like IPI, find the way forward.
Having made this statement as an introduction to my answer, I’ll now float the prediction that Java will in fact improve in the ways that we have in mind. Assuming that, Java is destined to have very far-reaching effects, much of which cannot be foreseen at the moment. Here are a few discernible consequences:
Leveling of the playing field, to coin a phrase. This will come about because, as Java technology replaces proprietary aspects of competing RTOS products, the feature set of the proprietary RTOS will be deemphasized. Java technology will replace a lot of tasking models.
A greater emphasis on the network, which is inherent in the Java environment. Third-party arrangements that we now maintain in order to provide TCP/IP and other communications packages are likely to be less important.
- It will become easier for IPI to offer complete solutions to a larger variety of customers.
Rinaldo: Given the fact that Java is beginning to be seriously considered for use in real-time business, what changes will you make to your current product line?
Bernard: IPI is now integrating MTOS with Java. The MTOS products will be redesigned to support Java threads and the various facilities that Java needs in order to function in an embedded environment. In addition, certain valuable MTOS features will be retained. Chief among these is support for multiple processors. This feature is transparent to the application and will be transparent to Java as well.
Rinaldo: Any ideas on what the size of the real-time segment of the Java market will be?
Bernard: This is not an easy question, especially since the availability of Java itself is likely to have a significant effect on the entire real-time market.
The market as a whole has a wide variety of components, which are offered by an even wider variety of suppliers. Estimated current market sizes are:
Vendors of RTOS products 50,000,000
Vendors of compilers, debuggers, and other tools 50,000,000
*"In-house" providers of RTOS and other tools UNKNOWN
*(The size of the "in-house" segment is estimated to have a value at least as large as the value of the products provided by the "vendors.")
Can Java capture a substantial part of the market? Probably yes; obviously we won’t know for sure until we have more experience on which to base our predictions.
Rinaldo: You argue that Java is likely to play a leading role in embedded systems. Can you justify that claim?
Bernard: That question is best answered from Dr. David Ripps, IPI’s VP for engineering. The following paper describes some of the work currently going on at IPI to provide a platform that integrates legacy real-time products with Java.
David: I base my prediction on several observations.
First, because of the importance of the Web, many programmers will be forced to learn Java. Eventually, universities will switch from C to Java in introduction to high-level languages courses. Once programmers become fluent in Java, they will naturally want to apply the language to areas beyond the Web — to embedded (real-time) systems, for example.
Secondly, the companies that develop real-time systems want the flexibility to move to hardware other than that for which the system was originally targeted. This requires that the programs be portable across hardware platforms and even instruction set architectures. C provided some portability. But, embedded programs must be structured as a set of independently-executable threads or tasks. C does not have any such an execution unit as an inherent part of the language. Nor does it have mutual-exclusion or any other method to protect shared data. Programmers have to get threading, protection, coordination, and communication services from a proprietary OS. Some OSes, such as MTOS-UX, make all services available for a wide variety of CPUs; many OSes do not. By building threading and data protection directly into the language, you can port a Java program to any (Java-enabled) platform, and the program works the same way. At least in principle.
Rinaldo: You speak of embedded or real-time programs. What is your definition of real-time?
David: A real-time system is one in which timing constraints imposed by the world outside of the computer play a critical role in the design and implementation of the system. Common areas for embedded systems are machine and process control, medical instruments, telephony, and data acquisition.
Rinaldo: Java seems to be a natural for embedded systems.
David: Java is certainly attractive as an alternative to C augmented by a real-time OS. However, you pay a price. Java does not have a rich set of coordination primitives. The programmer is forced to construct such common coordination objects as mailboxes and multi-bit event flag groups at the thread level from the few built-in facilities. This produces code that executes significantly slower than having such services provided at the kernel level.
Rinaldo: How sure are you that Java will live up to its expectations?
David: The need for a universal programming standard has been around since the days of Fortran. But industry has been burned before by promises of a universal, real-time-capable language. I am thinking of Ada. Despite high expectations and government mandates, Ada never displaced C for embedded systems. It is still too early to be absolutely sure that Java will become a force outside of network programming.
Rinaldo: How quickly might Java invade the embedded marketplace.
David: There is an enormous number of embedded systems that are currently written in C. Few companies are going to toss out that investment and rewrite it all in Java. There will be cautious experiments in using Java for new products that do not have a critical delivery schedule. If these projects work well, we may see hybrid systems going out into the field: mixtures of legacy C code and Java components. Eventually, new systems will be pure Java.
Rinaldo: Can you mix C and Java on an embedded target?
David: Yes, but only if your kernel or OS was designed with such support in mind. For example, if a Java component creates a new thread and a C component creates another new thread, the OS must be prepared to handle both threads in a compatible manner. Otherwise, the Java code and C code will end up fighting each other for control, and the system will be a mess.
Summary
I still have many questions that could not be explored because, as of this writing, some of the critical information on JavaOS is not complete. In future articles I will try to get other industry luminaries to speak on some of the following topics:
Comparison of performing some real-time critical task with Java ADA and C/C++.
Lessons to be learned from the ACVC (Ada compiler validation suite)
Issues with getting Java accepted as an option for life-threatening systems. It is obviously safer than C++/C (ignoring the run time), but how would it handle a head-to-head bake-off with ADA (which defines the run time). Will the reference implementation define the run time in greater detail or will Solaris threads, Windows 95 threads, Windows NT threads, and JavaOS threads produce five different results?
Is the lack of control with the garbage collector a big issue for real-time developers? I understand Microsoft has rewritten the garbage collector for their product in Internet Explorer. Will there be opportunity for Java classes that replace the standard classes? After all, in a real-time system you are not likely to be running productivity apps or are you? I guess the real question is: Will the myriad potentially specialized implementations impact portability?
- How can the Java community deal with tough problems such as:
- Priority inversion
- Quantum schedulers
- Soft real-time
- Hard real-time
The real-time world can be much more dangerous than the Web world. Financial loss is one thing, loss of life is another. It is important to realize that Java was not designed for real-time mission-critical environments, yet it has much promise to become a standard in this area.
