Java's three types of portability
Find out about the types of portability Java supports, and how Microsoft could undermine the technology by subverting the
one type that most threatens its hold on the desktop operating system market
By Mark Roulo, JavaWorld.com, 05/01/97
- Digg
- Reddit
- SlashDot
- Stumble
- del.icio.us
- Technorati
- dzone
Page 2 of 6
In short, although the syntax of C and C++ is well defined, the semantics are not. This semantic looseness allows a single
block of C or C++ source code to compile to programs that give different results when run on different CPUs, operating systems,
compilers, and even on a single compiler/CPU/OS combination, depending on various compiler settings. (See the sidebar Syntax versus semantics for a discussion of the differences between semantics and syntax.)
Java is different. Java provides much more rigorous semantics and leaves less up to the implementer. Unlike C and C++, Java
has defined sizes and endianism for the atomic types, as well as defined floating-point behavior.
Additionally, Java defines more behavior than C and C++. In Java, memory doesn't get freed until it can no longer be accessed,
and the language doesn't have any uninitialized variables. All these features help to narrow the variation in the behavior
of a Java program from platform to platform and implementation to implementation. Even without the JVM, programs written in
the Java language can be expected to port (after recompiling) to different CPUs and operating systems much better than equivalent
C or C++ programs.
Unfortunately, the features that make Java so portable have a downside. Java assumes a 32-bit machine with 8-bit bytes and
IEEE754 floating-point math. Machines that don't fit this model, including 8-bit microcontrollers and Cray supercomputers,
can't run Java efficiently. For this reason, we should expect C and C++ to be used on more platforms than the Java language.
We also should expect Java programs to port easier than C or C++ between those platforms that do support both.
Java as a virtual machine: CPU portability
Most compilers produce object code that runs on one family of CPU (for example, the Intel x86 family). Even compilers that
produce object code for several different CPU families (for example, x86, MIPS, and SPARC) only produce object code for one
CPU type at a time; if you need object code for three different families of CPU, you must compile your source code three times.
The current Java compilers are different. Instead of producing output for each different CPU family on which the Java program
is intended to run, the current Java compilers produce object code (called J-code) for a CPU that does not yet exist.
(Sun has announced a CPU that will execute J-code directly, but indicates the first samples of Java chips won't appear until the second
half of this year; full production of such chips will begin next year. Sun Microelectronics' picoJavaI core technology will
be at the heart of Sun's own microJava processor line, which will target network computers. Licensees such as LG Semicon,
Toshiba Corp., and Rockwell Collins Inc. also plan to produce Java chips based on the picoJavaI core.)
For each real CPU on which Java programs are intended to run, a Java interpreter, or virtual machine, "executes" the J-code.
This non-existent CPU allows the same object code to run on any CPU for which a Java interpreter exists.
- Digg
- Reddit
- SlashDot
- Stumble
- del.icio.us
- Technorati
- dzone
Resources
- Harbison and Steele, 1991, CA Reference Manual. Englewood Cliffs, NJ:Prentice Hall.
This book provides many good examples of differing behavior by different implementations of the C programming language.
- Alvin Toffler, 1990, PowerShift. New York:Bantam Books.
PowerShift provides a good discussion of how power, wealth, and knowledge interact. Toffler doesn't provide a lot of predictions in
this book, but mostly focuses on trends already underway.
- Some programming language implementations that either support the JVM or run under it:
- Ada95
http://www.adahome.com/Resources/Ada_Java.html
This is a page of links to Ada implementations that emit J-code, a comparison of the Java language with the Ada95 language
and other Ada links.
- BASIC
http://www.mcmanis.com/~cmcmanis/java/javaworld/examples/BASIC.html
From the author:
This is a simple BASIC interpreter I wrote in Java. When you load this page a new window will pop up with the interpreter
running in it (well loading first). It's a primitive BASIC, uses line numbers, implements most of BASIC-80.
- E
http://www.communities.com/products/tools/e/index.html
This is the home page for a language that builds on Java. The site contains a whitepaper on the language, tutorial, programmer's
manual and other neat things.
- Forth
http://www.mistybeach.com
This site contains Misty Beach Forth. Misty Beach Forth is an implementation of the Forth language that runs in a Java environment.
It does not (yet) produce independent class files.
- Java
http://www.javasoft.com
This is the JavaSoft home page.
- Prolog
http://munkora.cs.mu.oz.au/%7Ewinikoff/wp/
This is the home page for W-Prolog, an implementation of Prolog written in Java.
- Rexx
http://www2.hursley.ibm.com/netrexx/doc-netrexx-2.htm
This is the home page for NetRexx, a dialect of the Rexx language.
- Scheme
http://www.copsol.com/kawa/index.html
This is the home page for Kawa Scheme. Quoting from the home page:
Kawa is an implementation of the Scheme programming language. It is implemented in Java, and compiles Scheme into Java byte-codes.
- In addition to this list, the folks at SIG are working on a version of Eiffel that supports the JVM:
http://www.sigco.com
- Lucent Technologies' Limbo is another programming language that produces object code for an imaginary CPU:
http://inferno.lucent.com/inferno/limbotut.html
- JavaOS provides a simple way to run Java applications:
http://www.javasoft.com/products/javaos/index.html
- For another approach to distributing CPU independent programs, see
http://www.ics.uci.edu/~juice/.
- "Microsoft splitting Java", by Michael Moeller, Talila Baron, and Norvin Leach, PCWeek, November 25, 1996.
This article discusses Microsoft's plan to release a Java language compiler that emits native Windows applications instead
of J-code.
- "DEVELOPER DILEMMAWhich is the real OS? -- Java on Road to Fragmentation", by Deborah Gage, Computer Reseller News, November 11, 1996.
This article discusses the battle between Microsoft and Netscape to extend the Java APIs to areas that Sun had, at the time
of the article, ignored.
- "Microsoft's Strategy on JavaEmbrace, Extend, Disparage", by Jeremy Carl, WebWeek, December 2, 1996.
This article discusses many things in a short amount of time. Among those things is Microsoft's belief that Java's cross-platform
capability is of limited value.
- "The Backstage Battle over Java", by Nate Zelnick and Jeremy Carl, WebWeek, December 16, 1996. This article discusses Java and COM.