Writing an Operating System: Has Java Replaced C?

From its beginning, Java has steadily replaced C. Java is a viable alternative to C. How far will it go? Is C in danger when writing an operating system?

This article considers the subject of writing an operating system. When writing an operating system, you have at least three choices: (1) Pure C. (2) Pure Java technology. (3) Combination of C and Java technologies.

It's the culture. Consistently, we choose not to use Java. But why? Is there something inherently wrong with the technology? No, I blame the culture, not the technology. We choose to a language because of both social and technical benefits. Because it scores so high on social benefits, C is not in danger.

Technical benefits. While C requires more from a programmer, C can do things that Java can't easily do. Build a virtual memory manager, preemptive multi-tasking, a boot loader, a self-contained executable program. We expect an operating system to keep on running after an application crashes. We expect an operating system to reclaim resources after a process ends. We do not yet expect this from Java itself.

Social benefits. As technicians, most of us understand the technical benefits. But how many technicians think about the social benefits? When every programmer on an operating system project knows C, every programmer is trained in C culture, a value system associated with C. When C programmers work together, they share a common background and experience of systems programming. They inherit a rich culture from a POSIX-style of programming. They also inherit a culture of high expectations for community and vendor support. On the other hand, Java programmers inherit a different culture, based upon application programming, and thus lower expectations.

• For example, what C programmer would distribute a dynamically shared library without a version number embedded in the library name? On the other hand, what C programmer would use it? It would be unthinkable! And yet, Java programmers do it all the time.
• What C programmer would change the interface of such a library without regard to backward compatibility? As a consumer, what C programmer would put up with that? C libraries are not automatically backward compatible. No, the C language must be used in a specific way and this is what C programmers are taught. Best practices are taught within a culture. And again, Java programmers are missing something.
• In the OSGi module system, a programmer is taught to assume that a module will not be compatible with the next version. But what does that say about the Java culture? Java culture teaches a programmer how to write an unusable program.

Defeated by culture, overcome by culture. Java culture defeated early efforts to combine Java technologies with the operating system. Look at the heroic effort of JPackage.Org. Java culture makes it difficult to distribute with RPM. So JPackage.Org overcame the Java culture by creating a culture of its own. With RPM, we assume that an RPM will be compatible with a certain version and higher, until proven otherwise. The difference is huge.

A combination of C and Java could be a better choice. We are not required to write an operating system in just one language, are we? Why not use the best of C and the best of Java? We are starting to see products based on a combination of C and Java. So C is going to be around a while. Has any programming language ever died? (See also ASM, COBOL, FORTRAN, Lisp, Perl, PROLOG, SGML, Smalltalk.)

A pure Java operating system remains elusive. What about tomorrow? A combination of C plus Java technologies makes sense. Any programming language that runs on the Java Virtual Machine can be used to write the operating system, system libraries, system commands, device drivers, and applications. A module system is a necessary first step. Over time, as Java itself improves, as best practice improves, as module systems improve, fewer lines of code need to be written in C. A Java-based operating system depends upon a widespread knowledge of how to write Java properly for use in an operating system. A cultural shift is required. It is difficult, if not impossible, to overcome defects in a culture.

C remains a good choice. For many years, the C programming language has been a popular choice for writing an operating system. Some might say that it is the only choice. C provides many qualities we desire when writing an operating system. (1) Perfect binary backward compatibility is obtainable. With C, you can, for example, run a program written for Fedora Core 9 and run it unchanged on Fedora Core 12. (2) Separation of the interface from the implementation. With C, you can, for example, put the entire kernel API into header files. With Java, not so much. (3) Low-level access to hardware. With C, you can write software for any hardware.

Again, with Java, backward compatibility remains elusive. It can be done, but very few developers know best practices. A module system, such as OSGi, becomes critical because we want to use existing products but we cannot use directly. If everyone had written products correctly from the beginning, a module system would be simpler. But I blame the culture, not the language. Most Java programmers are probably both unaware and unconcerned about these issues because they are not using Java to write an operating system. Too many upstream APIs are unsuitable for an operating system because incompatibility is expected and planned.

Java borrows from C. It should be no surprise that the Java programming language borrowed heavily from C. It was intended to be an easy transition from C to Java. And from the earliest versions, the Java programming language has been an alternative language for writing an operating system. But Java has not reached its potential.

Here is a brief and incomplete review of the history of a Java-based operating system.

• 1996, "Java", Oracle (was Sun Microsystems)
• 1996, "JavaOS", Oracle
• 1997, "JOS", jos.org
• ?, "Eclipse", eclipse.org
• 2004, "JNode, jnode.org
• 2007, "Guest VM", Oracle
• 2008, "Android", Google
• 2009, "WebSphere Application Server Hypervisor Edition", IBM

JavaOS What ever happened to JavaOS? It booted across the network. It downloaded a JVM written in C. It downloaded standard Java class libraries from the network. Applications were written in Java and downloaded. This operating system was never intended as a replacement for Linux and Windows. But it demonstrated the potential for the C/Java architecture.

"Everything that can be written in Java should be written in Java." On the first original Java Lobby forum, we discussed the potential of the Java language for writing an operating system. The Java Operating System (JOS) project was born. At the time, some parts of the operating system could not yet be easily written in Java. The JOS Project demonstrated that a Java-based operating system was possible. It also demonstrated that Sun Microsystems kept making decisions without any regard for writing an operating system. (1) Bloat of Java Class Library. Business APIs, such as JDBC, were added to the core. (2) Development of a separate J2ME specification to reduce bloat. (3) No support for modules, no module system.

With JNode, the operating system kernel is written in the Java programming language and compiled ahead of time on a foreign operating system. Some C programmers have said, "It's a trick!" They have been led to believe that it is not possible to develop an operating system in a programming language other than C. Go ahead. Try to find one line of C code in the source.

With Eclipse, you can already do just about everything within the IDE that you might do with an operating system. Some do not yet see the potential for Eclipse to become an operating system. But eventually, a separate operating system becomes redundant. Why not just boot directly to Eclipse?

Does Android surprise you? Java is used wherever possible. The C programming language still has a place. It is set aside for anything that the Java programming language cannot yet do.

WebSphere Application Server Hypervisor Edition is a commercial product from IBM. They started with Linux, removed everything that was not needed to run WebSphere, a J2EE application server. Like Android, the C language is used to build enough of a platform to run the JVM. Applications are written in Java.

Conclusion: Culture is the problem. Culture determines what is possible. You cannot build and maintain an operating system in Java for as long as Java culture teaches that it cannot be done, and should not be. A culture of system programming builds an operating system. The programming language is not the problem.