Most read:
- The case for Java modularity
- Four harmful Java idioms, and how to fix them
- iBATIS, Hibernate, and JPA - Which is right for you?
- Build the enterprise with EJB 3, JBoss Seam, and Maven 2
- Hello, OSGi, Part 1: Bundles for beginners
Popular archives:
Java Q&A Forums - Let the great migration begin
We're pleased to announce the first phase of the integration of the Java Q&A Forums with our community platform, JavaWorld's
Daily Brew. Whether you're one of our longtime forum users or a brand newbie, we hope you'll visit the Java Q&A Forums in their new home alongside JW Blogs.
Featured Whitepapers
| Enterprise AJAX - Transcend the Hype |
| Oracle Compatibility Developer's Guide |
Java for embedded systems
An introduction to using Java in embedded systems
Java is a high-level language with which to write programs that can execute on a variety of platforms. So are C, C++, Fortran and Cobol, among many others. So the concept of a portable execution vehicle is not new. Why, then, has the emergence of Java been trumpeted so widely in the technical and popular press?Why is Java different from other languages?
Part of Java's novelty arises from its new approach to portability. In previous High-level languages, the portable element was the source program. Once the source program is compiled into executable form for a specific instruction set architecture (ISA) and bound to a library of hardware-dependent I/O, timing and related operating system (OS) services, portability is lost. The resultant executable form of the program runs only on platforms having that specific ISA and OS. Thus, if a program is to run on several different platforms, it has to be recompiled and relinked for each platform. And if a program is sent to a remote target for execution, the sender must know in advance the exact details of the target to be able to send the correct version.
With Java, source statements can be compiled into machine-independent, "virtual instructions" that are interpreted at execution time. Ideally, the same virtual code runs in the same way on any platform for which there is an interpreter and OS that can provide that interpreter with certain multithreading, file, graphical, and similar support services. With portability moved to the executable form of the program, the same code can be sent over the net to be run without prior knowledge of the hardware characteristics of the target. Executable programs in the Java world are universal.
In principle, portability could have been achieved in the C or C++ world by sending the source program over the net and then having the compilation and linkage done as a pre-step to execution. However, this approach would require that the target system have sufficient CPU speed and disk capacity to run the sophisticated compilers and linkers required. In the future, network platforms may not have the facilities to run even a simple compiler.
Is that all?
Java is not just a new concept in portability. The Java language evolved from C and C++ by locating and eliminating many of the major sources of program error and instability. For example, C has an element know as a pointer that is supposed to contain the address at which a specific type of information is stored. However, the pointer can be set to literally any address value, and by "casting" a programmer can trick the compiler into storing any type of information at the arbitrary pointer address. This is convenient if you write error-free code, and a snake pit if you don't. Java does not have pointers.
Equally important, Java has built-in support for multiprogramming. C and its immediately descendent C++, were designed to express a single thread of computing activity. There was no inherent support for multiple program threads executing simultaneously (on multiple CPUs), or in parallel (timesharing a single CPU). Any such facilities had to be supplied by an external multiTasking operating system. There are several good programs of this type readily available, such as MTOS-UX from Industrial Programming. However, the services provided are all vender-specific. Nether ANSI nor any of the various committees set up to hammer out a universal set of OS services ever produced a single, universally-accepted standard. There are in fact, several proposed standards, so there is no standard.
